Harvard Business School professor Clayton M. Christensen coined the term ‘disruptive technology’ in his 1997 best-selling book, “The Innovator’s Dilemma.” Christensen states that disruptive technology lacks maturity, often has performance problems, appeals to a limited audience, and may not yet have a proven practical application. As an unused, unapplied and untested alternative, it takes time for disruptive technology to be predominantly deployed.
However, because disruptive technology is new it has certain advantages, enhancements, and functionalities over competitors. This technology consists of ground-breaking products that significantly alter the way businesses or entire industries operate, and ultimately renders existing technology obsolete. Examples of disruptive technology are Email and Cell Phones.
Disruptive technologies are sometimes described as being simultaneously destructive and creative, with the power to change the way we work, live, think and behave.
American Express provides the following descriptions for their SMB programs (click to download PDF):
US AP Automation Overview
Synaptic Product Sheet
No, of course, you do not have to integrate all your systems. There’s an easy rule to follow to determine which systems should be integrated. Your goal should be “One Time Entry, Closest to the Source of Origin”. That means if any systems require entry of the same piece of information causing duplicate entry work in the organization, then most likely those systems should be integrated. “Closest to the Source of Origin” means that typically the first person/role that receives the information should be entering it into one system to feed all the systems.
Think about what makes the Microsoft stack so appealing…they have integrated their products as much as possible and they keep going for more. If a user is set up in the Outlook Exchange Server, they that same user is available in SharePoint, Delve, Sway, O365, etc. You should want that same level of efficiency in your own organizations. If you need help with the concepts or putting this into play, give us a call. We’ve got decades of experience in just this philosophy.
It’s best to be analytical when determining a what system is a good fit for your company. Start with a list of requirements and a wish list. Rate these items on priority (high, medium, low, etc.). It is often helpful to have a weighted average on the specific requirements.
Next, meet with the key stakeholders and get in-depth input. Be sure to include the technology platform and support in your requirements. From this you can develop your RFP (request for proposal). These requests should be sent to 5 or 6 software companies that initially meet your needs. Based on the responses and the related scoring, reduce the field to 3 players and then request a demo of each. Be sure you have your requirements of what you want in the demo; this is a scripted demo.
Of course, you are getting the quotes for initial outlay in cost and the ongoing costs. Factor in the cost of implementation as well. From this comparison, you should be able to determine the best fit for your organization.
Remember, this is not your normal skill set. Frequently companies use Cornerstone to guide them through this process, including predesigned templates and letters. We not only have experience in small to large RFPs, but we know most of the systems out there. That inside knowledge often helps tip the scale for the searching company to the best fit.
If you are not in the IT, Legal, or Audit department, first seek out a data security, privacy, or IT auditor staff member. If you have more than one of these individuals on staff, you may need to talk to multiple people to get you started. Certainly you will need to work with one or more of these people (if you have them on staff) to obtain necessary compliance.
There are many regulations surrounding data security and whether you need to comply with them depends upon what type of data you process, how you collect, process, and store it, what type of company you are, where you are located and more. Here are some of the types of regulations that exist today:
> PCI-DSS: If you accept credit card payments for any type of purchase, you must comply with this regulation.
> Sarbannes/Oxley (SOX): If you are a publicly traded company, you must comply with this regulation.
> GDPR: If you process personal data from EU residents (even temporary residents), you must comply with this regulation. Canada residents are also protected by “CASL” and US residents are protected by the “CAN-SPAM” act.
> GLBA (Gramm-Leach-Bliley Act): Compliance to this regulation is required by banks and financial institutions.
> HIPAA: The Health Insurance Portability and Accountability Act applies to all companies who collect, store and process personal medical information.
Note: when researching regulations/laws that your company needs to comply with, be sure to search for state and local laws as well as federal and international. Many states like California and Massachusetts have their own relevant compliance requirements.
Many software systems can be configured to authenticate to your network account repository – the most popular one being Active Directory. The primary advantage for users is one password for access to multiple systems. For administrators it is also being able to deactivate an account in one central location for all systems. If you are using Active Directory you can then apply policies around user’s accounts as well.
So, for ease of management and to be able to apply available management tools, having central authentication is a time (and therefore money) saver for both users and administrators.
On the downside, authenticating to one repository for multiple systems means that if a password is compromised an unauthorized user could potentially gain access to all systems the authorized user has access to. In addition, if that repository experiences an outage users could be locked out of multiple systems. Thus, make sure you plan accordingly and implement best practices for security before switching to central authentication.
Click Dimensions is integrated with Microsoft Dynamics 365 (CRM). This means when you login to CRM, you will see Click Dimensions options included with CRM options on most menus. Click Dimensions offers not only typical menu options for mass emailing marketing materials, but also collects website visit information like Google Analytics does (they are not the same but both supply similar information). Because it is integrated with Microsoft CRM, Click Dimensions can automatically update Contacts, Leads, and Accounts, and make use of custom workflows to gather more information on how your marketing efforts are progressing in real time.
The strategy needs to include not only budgeting of dollars but also timing. You should always be looking at this based on a minimum of two years. But, start with one year and you will see how easily you can roll into 24 months. Tie your strategy plan to your company’s fiscal calendar year.
Include in your plan the items, the timing, the reason, the dollars and the manpower. You should also include risk factor analysis for each item. This will help you identify potential hiccups ahead of time and be ready to respond quickly.
The best approach to an IT strategy plan needs a two-prong approach.
The first channel is based on what the IT team knows needs to be done to support the organization’s infrastructure. This includes things like server/hardware upgrades, cloud-based changes, major software updates, security systems, etc. You will also want to include IT staffing projections to support the company and the projected plans.
The second channel is to be sure you are aligned with the organization. Two to three months before your year end, you should meet with each functional area lead and get their plans for the upcoming 12-24 months. Learn things like head-count planned, initiatives projected, etc. Remember to include major initiatives such as an acquisition and minor initiatives such as a staff reduction. The IT plans should be interwoven with the entire company. It sounds simple, but adding staff to the AP department translates to more client machines and licenses, as well as additional support from IT. Do you have enough staff to support the planned growth?
By documenting your plan, you will be able to substantiate any budget and/or initiative changes for things that were not planned from other departments.
Remember, your overall goal is to be proactive instead of reactive.
Project cycles today focus on short term accomplishments to better deploy functionality while keeping the business running. Overall, this increases the probability for project success. Security requirements have long been associated with compliance, and thus have been considered long term goals. One of the reasons for this is because compliance is commonly assessed on a 6-month or annual basis, and then corrections are made.
In recent years, however, compliance and security have been evolving to include continuous monitoring, meaning security measures are largely in place and the process for evaluating them has matured. Changes to systems and the network environment are more likely to be controlled, and user access reviewed regularly.
This means that while your project may be creating new functionality or implementing new systems, these changes may need to ‘fit into’ an overarching security foundation and framework already in place. And, of course, if you don’t reach out now to determine what the requirements are, you will be setting yourself up for potentially costly rework later when the regular compliance assessment is completed.
First, let’s look at a comprehensive definition of Business Continuity:
Ensuring that the critical operations of a company can continue without stoppage; the capacity to restore systems to a pre-defined level of operation; and the ability maintain acceptable customer service, including delivery of products or services, irrespective of adverse events and following any disruption.
As we can see, Business Continuity includes recovering from any business interruption, which could be as small as a few minutes to as large as recovering from a disaster. Therefore, Disaster Recovery is actually only one part of a larger Business Continuity Plan.
The reason that Disaster Recovery is more familiar is because this type of recovery is the most extensive type of recovery and it gets more press. Truth is, disruptions to business happen all the time but usually companies can provide work arounds quickly enough that those disruptions don’t significantly impact customer service. The key question is, are you using the most efficient method in your recovery?
The goal is to create plans that address all types of potential disruptions, agree on which systems and processes will be addressed first, and have contingencies for a wide range of scenarios. For example, what if no one is available to execute the plan? Could a disaster far away impact your business? What about a hazardous incident on the nearest highway, at your nearest electrical station, or a fire in the offices next door?
To be able to build out their plans and create contingent manual processes if necessary, all departments will need to agree upon the order in which systems will be recovered and which processes take precedence. And IT will need to create their plan to incorporate these requirements alongside their own. When you have developed well thought through and tested plans, you will be able to withstand any size outage with the smallest affect possible to your bottom line.