In a world that is increasingly automated, many organizations immediately look to software to increase efficiency and reduce the number of people required to perform a process. As a result, many look to business continuity (BC) software to streamline and strengthen their BC programs. When the right software is selected and the process is implemented correctly, software can centralize oversight and management as well as enable a deeper understanding of the program. However, all too often, companies fail to fully analyze their needs before buying and purchase a tool that either becomes a nightmare to manage or sits unused. The purpose of this article is to discuss how to successfully implement BC software to fully support your business continuity program.
If you have not already purchased a business continuity tool, make sure the software is right for your company’s culture and BC structure before buying! A lot of companies buy in to the marketing that a software tool will solve all of their BC problems, but no BC software can do this unassisted. The most often cited reasons for not using BC software after purchase are either a lack of resources to sustain the software or the ease of use for the software is low and therefore loses user acceptance. No software is “one size fits all”, so organizations need to ensure a software product “fits” their company’s needs and culture.
BC software is only as successful as the “supporting structure” upon which it is initially implemented and then maintained. Some software products work better for organizations with a central BC group, while others are more appropriate for organizations where data and plans are user-maintained. Software that utilizes relational databases to build relationships between BC components may require data to be centrally managed with “systems of record” as data feeds, a structure that doesn’t work for all companies.
In any case, fully analyze the “true” software sustainability requirements (not just the marketing hype) against what structure is most appropriate for your organization to ensure that the software actually benefits your organization. To do this successfully, bring all key players into the requirements-defining and software purchase decision-making process, including executive management, any end user representatives, and IT personnel responsible for supporting the software and data feeds. Gather the expectations and requirements of each of these groups, as well as understand what support each will be able to provide and how these compare to the needs of the software product. If all key players are not on board and willing to commit the time and effort required to support the software product, the implementation will not succeed.
Once requirements have been defined and software has been purchased that meets these requirements, design a rollout strategy and timeline, clearing expectations with everyone needed to support the process. This may include user constituents responsible for providing data input or user acceptance testing or IT for production rollout and backup strategies, as well as managing any system data feeds. While this may be a Business Continuity Program tool, IT usually plays a significant role in rolling out and then supporting the software, so this group should be deeply integrated into the implementation process and be on board with any timelines for implementation.
For most software products, at least some system data needs to be entered and configuration performed before the software is ready for use by end-users. To do this, identify the appropriate sources for data input and determine if this data will be manually maintained or can be tied to other systems of record to automatically update this information. In addition, determine which data can be edited by end users and which data must be locked down and only updated through existing data sources or maintained by a central BC group.
If the software is configurable, determine if any screen or field changes are necessary to meet your data collection or terminology needs. While there are certain elements of business continuity that are considered “standard” or “generally accepted”, our industry is far from standardized, so companies should attempt to modify the software’s fields or terminology to match what is understood by business users (e.g. some organizations prefer maximum allowable downtime instead of recovery time objective).
Once the system contains data and has been modified to meet business needs, determine the appropriate levels of user permissions based on how confidential your organization views the data. If plans do not contain confidential information, locking down system access may not be as critical to your organization. If plan or system data is determined to be confidential (containing secured information such as personal contact information), roles should not grant any more access than is necessary for the users to manage their plans. Roles and permission sets may need to be defined for specific BC roles, including those responsible for building plans, those responsible for approving plans, and those responsible for manually maintaining system data, to name a few.
After defining data sources, as well as who can access the system and what permission sets they will have, document these decisions in a BC software policy. This policy should also capture high-level management expectations for the use and maintenance of the software product. Also consider developing an operations and maintenance document to capture specific data maintenance requirements and procedures for changing software data or screens, in line with change control policies.
When the system has been populated and configured properly, implement the changes in a test environment for both quality assurance testing and user acceptance testing. After quality assurance testing has been performed, develop a list of users who require access to the system in production, then set up a sub-group of these users to participate in user acceptance testing, to ensure the system meets user expectations and is user-friendly. Once their feedback is compiled, implement any necessary changes to address their feedback before the system is moved into production.
In preparation for the go-live date, roll out the system into the production environment after cleaning any “practice” data entered during the UAT. Set up the user accounts in the production environment, assigning the appropriate permissions. Before allowing users to log into the system however, it is HIGHLY recommended that in-person or online training and a user guide be developed to introduce employees to the BC software tool. This step is often overlooked, yet it is crucial to preparing users to accept the system and feel comfortable in using the tool. If users do not feel prepared to utilize the new software, they won’t, which will make all previous efforts in this implementation process futile.
Once the system is rolled out into production and users are regularly logging into and using the software, continue to gather user feedback and requests for changes that can be compiled and implemented into the next software update, in line with the maintenance policy.
While each BC software tool is unique, the steps outlined in this article are designed to capture general practices that can be implemented to increase an organization’s odds of success in rolling out a new BC software product. Overall, getting the support and buy-in of all critical stakeholders throughout the entire purchase and implementation process is by far the most important step in successfully implementing a new BC tool, though other steps discussed, such as user acceptance testing and user training, also prove to be critical in successfully managing the process.