ArcWorkbench modules by Draxmont Owl

Create Users and assign them to Projects. There are two types of user - Project Teams users and Delphi users. Delphi users are normally client staff, who have restricted access to certain applications associated with analysing the business process model, giving views on current activity and the effectiveness of current systems and processes.

Rename ArcWorkbench Phases and Applications, to relate more closely to your own terminology.

Activate or De-Activate Project Phases and Applications, when they are not relevant to a Project. For instance, a Project may only be concerned with implementing a system, without undertaking Business Process analysis and system selection activity.

Import and Export System Design elements, such as Tables, Forms and Reports from one ArcWorkbench environment to another.

Provide a Copy of ArcWorkbench to the client, incorporating all findings and deliverables.

Development Estimate Standards

Define standard development tasks and resources. You can define any number of standard tasks that you expect to have to undertake with projects, and any number of resources that you expect to be involved.

Specify standard time and resource costs. Standard tasks can be associated with time estimates for different levels of complexity. Resources can be assigned hourly charge rates. The Change Requests application can use these standards for determining change cost estimates.

Out-of-Box System Design

Define Out-of-box Systems and their Applications, Code Procedures, Forms or Presentation Screens, Reports, and Table Objects. System Design details would normally be imported either directly from the external system itself or from other ArcWorkbench environments that retain the system's design. ArcWorkbench provides facilities to do this. However, you can enter design details directly if such import procedures do not exist for a particular system.

System Configuration Elements

Define Configuration Elements for a system. A system can have a number of settings against which you can assign values that affect its behaviour and processing logic. You can enter these configuration elements either directly, or import them from another ArcWorkbench environment that has the same system registered within it. Once the elements are defined for a particular system, then for each Project defined in ArcWorkbench you can assign the values that apply to that Project. A configuration setting can be defined as applying to all sites or individual sites. You can assign a default value for each configuration element. For a particular Project, you can change the default values by using the System Configuration application, located in the Prototype Development module.

Project Set-up

Create new Projects. An ArcWorkbench environment can contain any number of Projects. When you create a new Project, ArcWorkbench automatically copies a Template directory structure to the new Project. You must retain this directory structure, but you can copy your own standard documentation into the template directory structure, so that it gets copied to each project.

Assign Project Logos. You can assign two Logos to a Project, which will appear on the ArcWorkbench main screen and all reports. Typically, the Logos would be those of the client and the consultancy organisation involved.

Assign Systems to a Project. Within the System Administration application you register systems and their design within the ArcWorkbench environment. You can associate any number of these systems as relevant to a Project. Once registered you can monitor system design changes specifically for a Project.

Assign Sites to a Project. You specify one or more organisational Sites to be associated with a Project. System Configuration, Strategies and Processes can vary from Site-to-Site.

Assign Roles to a Project. These are organisational roles that can be assigned to Departments and Business Processes.

Set up Change Request control. A cornerstone of the Arc methodology is that all changes made to a system's out-of-box design are associated with a Change Request. Each Project is set up with its own Change Request numbering system and approvers.

Activate or De-activate Projects. Although an ArcWorkbench environment can retain more than one Project, only one can be active at a time. To switch to a new Project, just activate it. All other ArcWorkbench screens will then display information about the activated Project.

Documents Set-up and Project Phase Deliverables

Register Documents to a Project. When you create a new Project, all of the documents that reside within the template directory structure, and which are copied to the project, are registered automatically as Project documents. Once registered they can be launched, viewed and worked on, from within ArcWorkbench. You can register additional documents that you may add to the directory structure after the Project is created.

Documents are either of type Deliverable or Reference. All documents copied from the ArcWorkbench template directory when a new Project is created are classified as Deliverables and are assigned automatically to the Project Phase associated with the name of the folder in which they reside. When you create a new Project you have an option to include all ArcWorkbench reports as a Deliverable as well. You can monitor the status of all Deliverables. You can add Reference Documents to the ArcWorkbench environment. These can be viewed by all Projects. They can be any document that is not to be classed as a Deliverable. Typically, they could be examples of completed deliverables to provide guidance on what is required, or any other background information for undertaking a Project.

User Application Access

Provide User Access to ArcWorkbench Phases and Applications, and Project Sites, Departments and Process Model Areas. You can restrict the view that each User has of Project Information. In this way, you can simplify user interaction with ArcWorkbench and also control development of Project deliverables.

Business Process Model Set-up

Create a Business Process Model to 3 levels. Define a Business Process Model for a Project as Process Areas, each of which has Processes and each Process can have a number of Tasks.

Define Sites. At the Process level, you can define the Project Sites where the Process is undertaken.

Map System Functionality to the Process Model. You can associate a Process Model with an aspect of system functionality, where functionality has been defined for the system and the system is assigned to the project. This will support later development of the Business Process model, where opportunities for process redesign, utilising available system functionality can be considered.

Import Process Models. Although Business Process Models can be built from scratch, you can import a model from another project or another ArcWorkbench environment. You can copy a complete model or just specific Business Process Areas or Processes.

When you import a model you can import a number of its attributes including Key Performance Indicators, Process Policies, Questions that you need to ask about the Process, and Process Inputs and Output. An appropriate model would be imported and then honed closer to the client's business profile.

Create a Process Model Bank. Typically, a consultancy could establish a bank of Process Models, in a central ArcWorkbench environment, relating to different kinds of organisation and processes. These can then be imported to a particular project and amended as required.

Site Departments

Define Site Departments. Sites are assigned to a Project when the Project is set up. For each Site you can define the organisational Departments that exist at the Site. With each Department you can specified the organisational Roles that exist.

Define Department Budgets. Departments can have an Activity budget, Capital budget and Overhead budget defined. Activity budgets can be defined at either the Department level or the Role level.

Defining existing Departments and their budgets provides a foundation for defining current activity and analysing it in the context of the Business Process model.

Department Activity

Define Department Role Activity. Department activity can be defined at the Role level. In doing so, you can assign a percentage of the Role Budget that the activity absorbs.

Define Department Activity. Activity defined at the Role level is automatically, rolled up to the Department level, with total Department activity budget percentages assigned. If Department activity has not been defined at the Role level, it can be defined directly at the Department level.

In a similar way to assigning activity to Roles, activity is defined and assigned directly to the Department, with budget percentage estimates provided against the Department budget as a whole.

Map Activity and Budget Costs to the Process Model. Current activities can be mapped to a Process in the Process Model. Once all activities have been mapped, Capital budget and Overhead budget costs can be assigned to the Processes. This provides a complete estimate for the current cost of Business Processes - mapped from Departmental activity.

Delphi Users. This is a Delphi User application. Ideally, Department managers should be given access to ArcWorkbench as Delphi Users, to specify current activity and their percentage allocations to the activity budget, and to estimate the allocation of Capital and Overhead costs to Processes.

Process Policies

Define Process Policies. At the second level of the Process Model, you can define Process Policies. These represent the fundamental beliefs and rules of the organisation that would impose constraints on how the detailed design of Processes must operate. They may be fundamental political policies or regulations, green or people issues that an organisation wishes to adhere to, or just a statement that the Board sets in stone that it will be done in a particular way.

Delphi Users. Process Policies can be assigned to one or more sites. Senior client managers should be given access, as Delphi Users, to particular ArcWorkbench Process Areas and Sites, to enable them to define the Policies that they think should be applied to Processes and the Sites that they should be applied to.

Process Area Questions and Characteristics

Define Process Questions. To understand the current operating environment impinging on a Process, a number of questions will need to be asked. Although the answers will be different from organisation to organisation, in similar organisations, with similar business processes, the questions are generally the same.

Some questions will be open questions (What, How, Why, etc.), others will be closed questions (How many, Yes/No answers, etc). Open questions elicit longer descriptive answers. Closed questions elicit short unequivocal answers. In ArcWorkbench Open questions are asked at the Process level. Closed questions are asked at the Process Area level (they are called Characteristics).

Delphi Users. Questions of both types are assigned to one or more Departments. Department managers should be given access as Delphi Users, to Process Areas and Departments within ArcWorkbench, so that they could be presented with appropriate questions for answering.

This doesn't preclude follow up interviewing by consultants, but does minimise the need for it and also gives Department managers the opportunity to consult with their staff and other managers before answering a question.

Process Key Performance Indicators

Define Key Performance Indicators. Key Performance Indicators (KPIs) are measures that indicate the efficiency and effectiveness of a Process. Some measures are associated with the cost of the Process, others are associated with the quality of its outputs (service quality).

For each KPI you can define its current value and its target value (where you realistically want to get to in the medium term). For measures associated with output service, you can additionally define similar values to represent how customers currently perceive the output quality, and how they would perceive it if the target KPI values were met.

Each KPI can also be associated with an expected financial benefit resulting from achieving the target value. This might be a reduction in cost or additional revenue income.

Delphi Users. Client managers should be given access to particular Process Areas as Delphi users. They should give their own views on KPI and service values and financial benefit expectations. In doing so, they have an option to view (anonymously) the values being prescribed by other Delphi users, to help them to reconsider their own views. Optionally, you can establish KPI values by taking an average of the values given by Delphi users. These average values could then be reviewed and adjusted by senior managers if required.

Process Inputs and Outputs

Define Process Inputs and Outputs. All Processes have Inputs and Outputs. Inputs come from other Processes within the Business Process model or from other external sources. Outputs go to other Processes or to external constituencies. These external sources and constituencies could be the same and include customers, clients, suppliers, regulators, public and many others. External Inputs might have a cost associated with them, and external outputs may have a financial benefit associated with them.

ArcWorkbench enables these Inputs and Outputs to be defined and their quality assessed. Process Outputs are defined first. Process Inputs would then be defined by selecting from the list of Process Outputs, or by directly entering an external input (from outside of the Process Model).

Delphi Users. Client managers should be given access to particular Process Areas as Delphi users. They should give an assessment rating for the quality of each Process Input. In doing so, they have an option to view (anonymously) the average assessment rating being provided by other Delphi users, to help them to reconsider their own views. Optionally, the average assessments of Delphi users can be used to establish the input assessment rating, which could then be reviewed and refined by senior managers.

Determine Process Output Quality. ArcWorkbench enables Process Inputs and Outputs to be synchronised. An Output is automatically categorised as "Input to Other Process", if it has been selected as an input to another Process. It is also automatically assigned a quality assessment rating that is the average value of the input quality rating given by all Processes that it has been defined as an input to. If an Output has not been selected as an Input to another Process it can be categorised as an external Output and a quality assessment rating can be assigned directly to it.

Business Process Rankings

Determine Process Improvement Potential. Analysing Current Process Activity, Key Performance Indicators and Process inputs and outputs enable you to rank the relative improvement potential of Business Processes from different perspectives. ArcWorkbench does this for you automatically.

It examines the costs of current Processes, the quality of their inputs and outputs, the potential they have for improving customer service, the potential financial benefits that improvement to them came bring, the capability of current systems to support them.

Reviewing the relative ranking of Processes from these different perspectives will focus effort to improve Business Processes and Systems and Service Strategy development.

System Functional Requirements

Define System Requirements. The Business Process Model will have system functionality requirements, at a relatively high level, which are unlikely to change with any changes made to the future detailed Process design. ArcWorkbench enables these requirements to be defined at the third level of the Process Model. Each Requirement can be assigned a rating of CERTAIN, PROBABLE or POSSIBLE, each with an associated score weight.

Current System Capability

Assess the Capability of Current Systems. The capability of current systems to address each requirement can be rated on a scale of NO FIT (0) to EXCELLENT FIT (9). ArcWorkbench automatically analyses the capability rating of current systems and identifies, for each Business Process, the extent that current systems support it, in a range from 0-100%. If a Process achieves 100% support then it indicates that all requirements are CERTAIN and current systems provide an EXCELLENT fit to each requirement. In conjunction with the relative importance of Processes, this analysis can provide focus on the extent to which current systems should be considered in the future system strategy.

Delphi Users. Client managers should be given access to particular Process Areas as Delphi users. They should rate the capability of current systems to support each requirement. They have an option to view (anonymously) the average rating being provided by other Delphi users, to help them to reconsider their own views. Optionally, the average rating of Delphi users can be used to establish the overall capability rating, which could then be reviewed and refined by senior managers.

Invitation to Tender

Manage Invitation-to-Tender. ArcWorkbench enables you to create and manage Invitation-to-Tender (ITT) procedures. An ITT can specify general background information, global requirements (e.g. supplier organisational information, IT security requirements, IT performance requirements, etc.), and Process requirements.

Process requirements can be automatically assigned to an ITT from those defined against the Business Process Model in the ArcWorkbench System Functionality Requirement application.

Potential Suppliers can be associated with each ITT. When the ITT is released for Supplier response, it is "Frozen", preventing additional requirements being added to it. If additional requirements are required to be added after an ITT is "Frozen", then these are added to an amendment to the ITT, and released to the Suppliers as a separate entity.

Distribute the ITT Requirements to Suppliers. When an ITT is "Frozen", the requirements are copied to a separate ArcWorkbench ITT application, which can be distributed to Suppliers. Suppliers can use this application to register their responses against the requirements, and then return it. Supplier responses can be automatically uploaded into ArcWorkbench, where they can be reviewed and assessed.

Supplier Response Assessment

Assess Supplier Responses. Supplier Responses can be either captured directly into ArcWorkbench or imported from the ArcWorkbench ITT application, returned by suppliers. The capability of a supplier's system/service to address each requirement can be rated on a scale of NO FIT (0) to EXCELLENT FIT (9). Supplier ITT Responses to each Process Requirement can be viewed and assessed from within the System Functionality Requirements application. The overall capability of each supplier system against each Process can be compared. The Requirements scoring mechanism provides a demonstrably objective assessment.

Delphi Users. Client Delphi users, with access to particular Process Areas, can rate the perceived capability of the supplier's system/service against each requirement. They have an option to view (anonymously) the average rating being provided by other Delphi users, to help them to reconsider their own views. Optionally, the average rating of Delphi users can be used to establish an initial rating for each Requirement, which could then be reviewed and refined by senior managers.

Develop the Process Model

Process Model Development. The initial Business Process model is established by Process Model Set-up application, in the Business Framework module. During Prototype development this model would be developed further. Processes and Tasks can be added, deleted, or moved to another position in the Business Process Model. The Business Process Model can be renumbered following such tailoring.

Tasks can be associated with Roles and Task Procedures. Task Procedures are documents registered in ArcWorkbench, which define a Task to a lower level of detail. Typically, this might be a flow diagram. Once assigned to a Task, the document can be open up and worked on within ArcWorkbench.

The Out-of-Box System design, specified in the System Administration module, enables application functionality to be defined against System Forms/Presentation Screens. This functionality can be associated with a Task, to show how the Business Process Model and System will match to each other.

System Change Requirements

Identify System Design Change Requirements. During Prototype development a number of requirements to change the Out-of-Box system design may be identified. Some change requirements may have been identified during the System Selection phase, others may be new. If required, requirements identified during the System Selection phase can be imported as change requirements.

ArcWorkbench enables you to define the nature of the change (e.g. a configuration requirement, a software development requirement, a report requirement, etc.), and to give each requirement a rating of CERTAIN, PROBABLE or POSSIBLE, with an associated score weight.

Control Change Requests. ArcWorkbench philosophy insists that before any system change requirement can be implemented it must be associated with an ArcWorkbench Change Request. One or more requirements can be assigned to a Change Request. Change requirements can be entered directly to a change request or can be imported from the System Change Requirement application (above).

Each change requirement line on a Change Request can have a number of development tasks, and development resources, associated with it. These development tasks and resources are selected from pre-defined tasks and resources established by the ArcWorkbench System Administration module. The resources have pre-defined standard hourly cost rates. The number of hours required from a resource can be changed from the standard number of hours that is defaulted.

Each change requirement line has its cost automatically calculated by ArcWorkbench and these costs are automatically accumulated to provide a total cost for the Change Request. All Change Requests must be approved by before they can be registered against System Design Changes. ArcWorkbench enables one or more approvers to be assigned to each Change Request. Once approved, no further changes can be made to a Change Request.

System Design Changes

Monitor System Design Changes. System Design Changes can be registered in ArcWorkbench, providing an audit trail back to the Out-of-Box System design. Design changes can be registered against Forms/Presentation screens, Reports, Code Procedures and Table Objects (Columns, Indexes, Triggers). The change may be associated with additional design objects, or changes to existing Out-of-Box design objects.

All changes (and additions) must be associated with an approved Change Request. When a change is implemented into your Project environment, you register it as confirmed within ArcWorkbench. Once confirmed, the change details cannot be altered. If you wish to make subsequent changes to the same design object you must register another change.

System Configuration

Register System Configuration Settings. In the System Administration module, you define configuration elements for each system. A system can have a number of elements against which, for a particular Project, you can assign values to these elements that affect the system's behaviour and processing logic for that Project.

A particular configuration setting will apply either to each site individually, or to all sites. ArcWorkbench automatically assigns default values for all sites, and individual sites, that are registered in a Project. These default values can be altered. For those elements that are assigned to sites individually, you can copy the setting values from one site to another.

Configuration settings can be associated with external documents. This enables more complex configurations to be recorded externally, in say a spreadsheet that is specific to that configuration. Such external documents are linked to the configuration setting in ArcWorkbench and the document can be opened up from within ArcWorkbench.

Test Procedures

Link Test Procedures to the Process Model. Test Procedures define the detailed system-user interaction steps required to undertake particular Tasks within the Business Process Model. Each step in a Procedure should define the expected system outcome, resulting from completing the step.

ArcWorkbench enables external Test Procedure documents to be linked to Process Model Tasks. These Test Procedures can be subsequently opened up from within ArcWorkbench.

Manage Testing. For each Test Procedure, registered against a Task, you can indicate whether the Procedure is ready for testing. You can record any number of tests undertaken, and the result of each test (Pass or Fail).

The Tester can register comments against each test. This is particularly necessary when the result is a Fail, to explain the reasons for failure. There is also a facility to reply to the Tester's comment. Such a reply may indicate what action is being taken to rectify a problem, or to explain if the Tester has misinterpreted the expected result.

Training Materials

Link Training Documents to the Process Model. ArcWorkbench enables external Training documents to be linked to Business Process Model Tasks. These documents can be subsequently opened up from within ArcWorkbench.

Develop Training Modules. In the Prototype Development application, Process Tasks can be related to a Role undertaking the Task. ArcWorkbench enables Training documents to be assigned to Role focused Training modules, by considering the Role assigned to a particular Task. These Training modules can be scheduled as Training courses within ArcWorkbench.

Data Migration Strategy

Define Data Population Strategies. Provided that the system Tables and their Columns have been registered as Design Objects with a Project, ArcWorkbench supports development of Data Migration strategies.

In defining strategies, Database Tables are considered within their Data Subject groups. Data Subjects group Tables together where they have a high inter-dependence of data between each other. These groups are defined and assigned to Tables in the System Administration Module (Out-of-Box System Design).

Tables are defined as either being populated, or not. If a Table is populated, then ArcWorkbench enables you to define how it is populated - either by data being entered manually through system screens or by a data migration procedure that moves data into the database automatically. A population strategy can be defined for either all sites, or a particular site.

Manage Migrated Data. Typically, a data migration procedure would involve collecting data into spreadsheets, converting the spreadsheets into text documents and loading the data by using a database SQL procedure.

ArcWorkbench can automatically identify all mandatory Columns required by a table, as a starting point for an individual Table's migration strategy. You can then add other columns for non-mandatory data that you wish to migration.

ArcWorkbench automatically identifies Foreign Keys and Sequences associated with a column. ArcWorkbench automatically identifies column attributes, such as type and size, even if these have been altered by System Design Changes. You can assign default values to each column, either as a fixed value or by reference to other Table Columns in the same Data Group.

Reconcile Population Strategies. ArcWorkbench can automatically reconcile your individual Table population strategies by ensuring that where a Table is dependent on data from another table, the other Table is populated. It also identifies the optimal sequence for populating tables.

Data Migration Scripts

Automatic Creation and Management of Data Migration Scripts. Using the defined Table Data Migration strategies, ArcWorkbench can automatically create Data Migration scripts (PL/SQL), and associated data collection spreadsheets. Data Subjects can have one or more migration scripts. Each migration script is created for one or more tables. Where one record in a table relates to one record in another table, their data can be migrated together in the same script. If a Data Subject has more than one script, ArcWorkbench automatically identifies the sequence that scripts should run.

For each Data Migration Script, ArcWorkbench creates a Spreadsheet, into which required data that is not being defaulted will need to be collected. If changes occur to the design of System Table Objects or Data Migration strategies, after a script has been created, ArcWorkbench warns that the migration script needs to be re-created.

Data Integrity Checking. After data has been populated into the script spreadsheet, it can be checked for integrity (data type, length, spaces, etc.) before ArcWorkbench automatically creates a data load text file against which the load script will be run to populate data into the database.

Cutover Planning

Create Data Cutover Plans. The episode of switching new systems into an organisation's day-to-day operations requires careful planning to minimise the risk and disruption to the organisation. ArcWorkbench enables you to produce a step-by-step plan for achieving cutover. If necessary, more than one cutover plan can be associated with a Project, to accommodate the phased implementation of systems.

The plan can be established and run in a test environment, where its integrity can be checked and the time required to undertake each step can be checked.

Calculate Cutover Downtime. ArcWorkbench automatically calculates the critical path time required to undertake the cutover, providing the organisation with the time that systems will be unavailable, enabling the organisation to establish temporary working arrangements.