Advanced Change Management Setup and Deployment

FLODocs Advanced Change Management uses all the components of the FLODocs system to help reduce the risk of mistakes while helping you move with greater confidence. The Advanced Change Management system uses a set of policy records called FLO Change / Approval Policies which define:

  1. The level of change management required for a given change (eg modification of a script vs a search)
  2. The level of approval required and the participants in that approval process.

When Process Issues or Change Requests are created, FLODocs analyzes the impacted customizations and process(es) and identifies the change policy that applies.  For example, a company may have four policies:

  1. A Default Policy that applies to any customization or process without a specific policy.  It would generally require that scripted changes go through a relatively high level of review compared to non-scripted changes.
  2. A Financial Processes Policy that would apply to the core financial processes.  Under this policy any changes to the financial processes could require full development and testing and also approval of the CFO, for example.
  3. A Critical Operational Processes Policy would apply to vital operational processes or customizations such as those comprising a critical integration, for example.  This policy might require approval by the CFO as well as the expert owners of the specific objects concerned.
  4. A Controls Policy that would specifically apply to key reports and controls, listed on the policy, that need very specific approval to modify in order to ensure there are no changes without a proper audit review.

Once in place, FLODocs policies remind users of the level of change management required as well as monitoring the changes that do occur and raising alerts to IT if change violations occur.

There are six steps in a standard deployment of Advanced Change Management module corresponding the key parts of the FLODocs system

  1. Automated Documentation:  Install FLODocs and start the spidering process to ensure that all customizations are fully covered.  Once complete, enable the autospider portlet on all Admin and Full Access dashboards to ensure all changes are captured.  For more information see the FLODocs installation section in this guide.
  2. High-Level Process Documentation:  Processes give meaning and ownership to the customizations as well as making the NetSuite account easier to understand.While the spiders are progressing, work can begin on building out the High-Level Process (HLP) documentation which describes the company in terms of large buckets of process.  In multi-organizational accounts, t is a best practice to initially describe the main operational company and then describe other companies with reference to that initial map.  For purposes of change management, the processes need only be described to the level required to meaningfully group the customizations in the account.  This is usually less than 50-60 process records.  Detailed documentation and swim lanes can be added later.
  3. Mapping Customizations to Processes:  Mapping customizations to processes is performed quickly and effectively using the metadata gathered by the spider.  Objects are mapped in order of decreasingly complexity starting based on Bundles, Scripts, Custom Records, Active Searches and Ad Hoc mappings (see Process Mapping user guide entry for deta.  This approach leverages the metadata allowing related objects to be mapped rapidly. Upon completion of this step, you will have an extremely well-documented account.There are three key approaches to mapping a customization to a process:
    1. Direct List Editing:  FLODocs provides a direct list editable field called Quick Add Process which enables you to quickly add a process to any customization or group of customizations.  This is generally the best approach for groups of less than 30 related customizations since it takes about 2.5 seconds to process each edit as FLODocs not only updates the customization with the process but also the process with the customization in the proper field.
    2. Mass Update:  Mass updates permit you to map many,  and some cases hundreds, of customizations at once. FLODocs includes a number of mass updates used to set the process on customizations based on:
      • Bundle
      • Related Scripts
      • Parent Records
      • Related Searches
    3. Process Assistant:  The Add Details page in the Process Assistant enables you to quickly search for and map specific customizations related to a process or a specific step in a process.  This is best used for detailed documentation of complex processes
  4. Specifying Process Owners:  FLODocs automatically identifies the process owners who will be affected by a change.  In order to contact the correct process owner(s) during the approval process, an owner must be assigned to each process.  Once an owner is assigned only that person or a user with Administrator or Full Access permissions will be able to edit the process, unless the owner appoints specific editors.  To specify an owner, open each top level process and select the desirable employee in the owner field.  At that time, the Update Child Owners field can be checked to update all child processes with the same owner (this may take a short time to save).  As a result, owners can be mapped to a large number of processes quickly and easily.  More specific process owners can be designated at a later date.
  5. Specifying Change Policies: FLO Change / Approval Policy records describe the level of change control that the company wishes applied in specific situations based on the type of object affected as well as the approvals required.
    1. Change Level: Change levels can be assigned to different categories of object including:
      • Scripted Objects:  Scripts, Workflows and any object connected to a script or workflow.
      • Controls: Searches, Reports, User Roles specified as a control on a process can be given tighter controls
      • Searches and Reports:  Searches and reports that are neither scripted nor specified as a control on a process. NOTE:  Reports are not  supported in the present release, they must be manually documented.
      • Set Up and Web Changes:  These are planned for upcoming support of these objects
      • Other Changes:  Changes to objects that are not in any of the above categories.
    2. Approvals:  Approvals are automatically calculated during change request processing based on the specified and impacted objects and processes as well as the settings on the change policy record.  Four different sets of approvers can be specified.  If left blank, they are skipped.  They are:
      • IT Approvers (First and Last):  These approvers control whether a change proceeds to operational approval and whether an approved change proceeds to development
      • Process Approvers:  These are the process owners (or their Editor surrogates) for the affected processes specified by IT or, if selected, the impacted processes.  If desired, parent process owner approval can be required, which would normally only apply to very sensitive processes.
      • Customization Approvers:  If desired, the owners of specific objects can be required to approve any change.  This would normally only apply to highly sensitive reports and searches or complex customizations where the specific expertise of the object owner(s) is required.
      • Management Approvers:  These are the second last approvers (before 'Last IT') and normally own the budgetary or compliance responsibility for customizations affecting the policy.
    3. Affected Processes and/or Customizations:  The final step is to specify any processes or customizations to which each policy applies.
      • Customizations are specified on the Customizations sub-tab or can be specified by selecting the policy on the Change / Approval Policy field on the Implementation subtab of The FLO Customization record. Each customization must be specified individually.  However, impacted customizations will be used to identify policies.  As a result, the policy relating to a critical script will also apply to any field affected by that script.
      • Processes are specified on the Processes subtab or by selecting the policy on the Change / Approval Policy field on the Continuous Improvement subtab of The FLO Process record.  Only the highest level processes need to be specified.  FLODocs will search hierarchically upward to locate the relevant policy.  In the event that multiple policies apply, the one closest in connection to the affected objects with the highest level of change control will be selected. As a result, usually only a few processes need to be tagged to each policy.

 

 

Mark Walker