UA Configuration Strategy by panniuniu

VIEWS: 0 PAGES: 14

									                                       The University of Arizona
                                                 Mosaic Project
                         Kuali Financial System Implementation
                                          Configuration Strategy

                                                                         Version 1.0

Revision History
         Date       Version                    Description           Author
12/3/2008          1.0         Initial Draft                   K. Horn
1/26/2009          1.1(1_2)    Revisions to initial            C. McAnarney
2/9                1.2 (1_3)   Revisions to tactical section   C. McAnarney
2/18               1.3(1_3)    Revisions based on PM review    C. McAnarney




Document1

                                 The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM




                                                Contents
1    Executive Summary                                                                             3
     1.1 Goal                                                                                      3
     1.2 Strategy Approach                                                                         3
     1.3 Challenge                                                                                 5

2    Scope                                                                                         6
     2.1 Configuration Strategy Deliverables                                                       6

3    Assumptions                                                                                   6

4    Stakeholders/Roles                                                                            7

5    Tactics                                                                                       7
     5.1 Maintain Configuration Data                                                               7
     5.2 How this process will take place . . . in actuality                                       8
     5.3 Validation of Parameters and Maintenance/Reference information                           11
     5.4 Load the master spreadsheets                                                             11
     5.5 Configuration verification                                                               11
     5.6 Workflow and Departmental Reference data                                                 12
     5.7 Approvals                                                                                13

6    Factors                                                                                      13
     6.1 Concurrent Projects                                                                      13

7    Strategy Roadmap                                                                             13
     7.1 High Level Timeline – Still in flux                                                      13
     7.2 Progress Monitoring                                                                      13
     7.3 Training                                                                                 13
     7.4 Move to Production                                                                       14
     7.5 Signoff                                                                                  14
     7.6 Document Management                                                                      14




Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM




                                  Configuration Strategy
1    Executive Summary
    1.1       Goal
The goal of this document is to define a strategy to be used to manage the successful configuration of the
Kuali Financial System to amply prepare it for transaction processing. This document will address the
strategy that will be used along with logistical and tactical directions for those configuring the Kuali
Financial System. The scope of this document is limited to the configuration of the Kuali Financial
System (KFS) and related university initiatives that impact the KFS implementation.

The intent of this strategy is to configure the KFS software to ensure that the software performs as
expected with respect to business processes in the various environments, as noted in the Environment
Strategy document, including testing environments and the production environment. Configuration can
be divided into three major classes, each of which will be addressed by the strategy:
    1. Reference/Maintenance Tables – sets of values for a given reference item. For example, the
        values for account.
    2. Parameters – system level setup decisions; most parameter setups are made once and will not be
        changed. These control the way the system operates. For example, the valid values that can be
        selected for payment type.
    3. Workflow and Roles – configurations that control access and workflow routing. For example, the
        approvers within a particular department that will approve a disbursement voucher.
    1.2       Strategy Approach
This section describes the overall strategy that will be followed for configuration. For example, the BSAs
will be trained on the configuration process, initial reference data will be established and must be
completed, initial parameter data will be established and must be completed, appropriate sign-offs will be
obtained, configuration data will be maintained and properly tracked, and cut-off dates will be
appropriately met. The high level strategy for achieving these goals and objectives include the following
sections that are described in further detail throughout this document.

As mentioned, configuring Kuali Financial System refers to the process of populating the values for the
maintenance, reference, and parameter tables that support each module and the system in general, as well
as configuration of workflow. The configurations are broken down into the following functional areas:

              Chart of Accounts, which includes accounts, object codes and organizations
              Vendor
              Financial Processing, primarily Disbursement Voucher
              Purchasing and Accounts Payable
              Labor Distribution
              Capital Assets
              Contracts and Grants
              General Ledger
              System-wide configurations

Maintenance/reference tables: Excel spreadsheets for each module have been created and are stored in
the KFS directory in folder 97 Data Conversion. Each module has its own workbook within the folder, as
well as some working documents related to considerations for the configuration of that module. Each
maintenance table for the module is represented by a worksheet within the workbook. Additionally each

Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


workbook has a tab that is entitled “log.” This tab is used to track changes made to any of the other
worksheets in the workbook, including adding new worksheets.

As with other software systems, some of the delivered maintenance tables already have data which is
included in the spreadsheets. The data that is contained in the tables that are delivered with data is
reviewed and modified to represent the configuration for the University of Arizona (UA). For example,
the Trucking Company maintenance table is delivered with trucking companies. UA will delete some of
these and add companies that are used by UA. When data is loaded from the spreadsheets existing data in
the tables will be overwritten.

The spreadsheets are used to load data into the KFS environments and are tested in the module that they
support.

As changes are discovered:

    1. The log sheet for the module is updated to indicate what values need to change and on what sheet.
    2. The change is made to the appropriate worksheet so that, at the next data load, the environment
       will have the most current data and we know what tables need should have been updated.
    3. The table within the given KFS environment is updated.

The BSAs for each module are responsible for updating and testing their reference tables. It is
acknowledged that some of the configuration changes will require some trial and error. It is important
that the BSAs track what changes they are making, but they need only update the workbook with the final
changes. They can, if they wish, use the log to track the changes through the trial-and-error period, but
this will not be enforced unless it is found that the spreadsheets are not being maintained, which will be
evidenced upon the next environment configuration refresh. The process of how the configurations will
be tracked and maintained and implemented into the various environments is discussed further in the
Tactics section of this document (section 5).

Parameters: A spreadsheet to track the parameters has been created and is stored in the Parameters folder
within the aforementioned 97 Data Conversion folder. Parameters for each module are represented as a
separate worksheet. The Parameter Coordinator (currently the GL BSA) has been given responsibility for
managing the parameters.

The parameters in the spreadsheet were downloaded from Kuali Financials with delivered values and
descriptions of what they do. The Parameter Coordinator is meeting with each module owner to review
the parameters and as changes are made, the new values are entered in a new column within the
spreadsheet and updated within KFS. As with the other module workbooks, a log worksheet is being
maintained within the parameters workbook that will track the changes to the workbook.

The BSAs for each module are responsible for testing the parameters and for coordinating changes with
the Parameter Coordinator.

It will be important for the environment team, the conversion team, and the testing team to ensure that the
environments are maintained appropriately and that appropriate configurations are propagated across the
environments at the appropriate times. Options for this may include:
     never reloading parameter tables, and always manually adding the values across environments
         (not very practical)
     maintaining values within the load process which are also being maintained within the
         worksheets (duplication of effort)
     always referring back to data from the spreadsheets for the load process
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM




Workflow and roles: We will need to set up workflow and roles centrally and work with departments and
units to help them set up their routing needs. This work is dependent on the Kuali Identity Management
module.

This effort is yet to be defined, but it is expected that the departments and units will be educated on the
process and related impact for which their workflow will be dependent. Individuals within each
department will then be responsible for the configuration. It is expected that there will be a method by
which the values within the departments configuration can be extracted and reviewed such that the
departments will be able to sign off that their routing configuration is complete and accurate.


All changes to the maintenance, reference, parameter, and/or workflow values that are found during
testing should be incorporated into a test case by the testing team. This will ensure that future rounds of
testing contain these same values. It may be deemed appropriate to not perform these tests at a later time
if the process of updating the spreadsheets and the environments appears to be working as designed.

In order for the departments to perform their configurations, the following must be done first: (1) Set up
Account, Organization and Object Code Loads and (2) manual adjustments to the configuration.




    1.3     Challenge
The biggest challenge in the process of configurations will be ensuring that updates are made in the
spreadsheet, the log is updated and that updated spreadsheets are loaded.

Special consideration will also need to be given to the department configurations that will occur, as it is
currently not planned to have the departments updating spreadsheets.

All of the above items in sections 1.1, 1.2, and 1.3 are further complicated by the fact that the 3.0 release
of Kuali has not yet been delivered. The data that exists in the spreadsheets as of January 2009 is based
on release 2.2, and not based on release 3.0, which is the intended release to be implemented. Without
having the new environment, it is conjecture as to whether the aforementioned process will continue to
work in all cases for configuration.

The process of system configuration will involve 3 methodologies, and may vary depending on phase of
the project and/or the environment to which the configurations are being applied. The 3 methodologies
are conversion, spreadsheet upload, and manual configuration. These methodologies may also be used in
conjunction with each other, especially early on in the project. As an example, much of the configuration
will be uploaded based on spreadsheets and converted data from FRS as of July 1, 2008 in our initial test
environment. If an issue with configuration is found in that environment, a change may be applied
manually initially to ensure that it is appropriately impacting that environment given the situation being
tested. The same change, after being documented in the appropriate worksheets within the appropriate
workbook, might be uploaded to the configuration environment, validated, and then all spreadsheets and
conversions from FRS will be initiated again during the next environment refresh, which would include
the newly modified value.

Initially, there may be a lot more of one method than another, but as the project gets closer to the actual
move to Production, the process of building the Production environment (and test environments, such as
that for User Acceptance Testing) should be solidified and followed via a script, regardless of the
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


method(s) employed to configure the environments.



2    Scope
This strategy is confined to configuring the Kuali Financial System Software. The system should be
configured to support business processes and reporting needs as defined by the approved business
processes.

    2.1     Configuration Strategy Deliverables
The following deliverables will be created to further support this strategy:
    o Master spreadsheets for each module, including a mapping from FRS to KFS as appropriate and
         supporting reference tables and values, as well as the related log worksheet for the given module
         workbook.
    o Mapping table in UIS
    o Parameter spreadsheet to track delivered and modified values, as well as the related log
         worksheet.
    o Configuration templates to be completed by departments and units for project codes, sub account
         codes, and sub object codes.
    o Configured reference tables and parameters within each environment.
    o Unit tests to support the assertion that the configuration process was complete and accurate
    o Workflow template for the departments and units to complete to facilitate manual configuration
         of their workflow routes
    o Signoff pages to be incorporated into initial testing for the departments’ workflow and chart of
         accounts values to allow them to assert that the upload was successful and appears to be
         functioning as planned.
    o Training documentation to explain how the process of configuration will be managed, updated,
         and maintained throughout the project
    o Training to explain to the departments what is needed of them and to articulate how they are to
         present the data to the project team
    o Tracking spreadsheet to monitor the status for each module’s reference tables, parametric values
         with a status indicator of Not Started, In Progress, and Complete.

3    Assumptions
         Sufficient documentation or knowledge exists to understand the implications of the decisions
          made regarding maintenance tables, reference tables and parameters.
         A KFS configuration environment will be available to test configurations.
         Configurations will be performed in various fashions, including manually entering values,
          loading values from the spreadsheets, and converting values from the FRS system. It is also
          possible that values may be copied from one environment to another (although this is not part of
          the current environment strategy). It is anticipated that values that are copied from one
          environment to another are a result of the entire environment being copied (e.g. using a “Gold
          Standard” environment that represents only the “pristine” values that have been confirmed to be
          the appropriate configuration values).
         Particular attention will be paid to ensure that the configuration documents are maintained with
          the up-to-date configurations that have been validated/invalidated through testing, including not
          only updating the specific worksheet for that configuration, but also updating the log sheet within
          the same workbook to reflect the update.


Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM



4    Stakeholders/Roles
For a detailed list of roles and responsibilities, see the document entitled “Roles and Responsibilities.”
The following roles are involved in the processes described in this strategy and each module and
parameter configuration should be assigned a person for each role:

          o     Business System Analysis (BSA) – The BSA will be responsible for ensuring that all
                reference tables and parameters in their assigned area are populated correctly and are
                maintained. They will work with the appropriate Business Process Owner, Subject Matter
                Experts, Departments, Units, and/or the Parameter Coordinator to ensure their module is
                configured properly.
          o     Parameter Coordinator (PC) – The PC is responsible for maintaining the parameter
                worksheet with the delivered values and UA values and to work with the BSAs, BPOs and
                SMEs to ensure parameters are configured correctly and that changes are recorded.
          o     Subject Matter Expert (SME) – The SME brings expertise to the configuration. The BSA
                may include Technical SMEs where necessary. There may be multiple SMEs and they may
                come from different parts of the organization (e.g., FSO, Colleges, Units).
          o     Business Process Owner (BPO) – The BPO is the person who has responsibility for the
                module and/or eDocs, many times manages the module/eDoc, and will be responsible for
                understanding the module/eDoc in detail. The BPO is not necessarily the person who works
                within the module or uses the eDoc, but is responsible for the outputs from the module/eDoc.
                There may be multiple BPOs and they may come from different parts of the organization
                (e.g., FSO, Colleges, Units). It is important that input and sign-off be obtained from all
                parties with ownership.
          o     Business Process Advisor – The BPA is the person who is ultimately responsible for the
                module but is not necessarily familiar with the module. The BPA is required to sign off on
                the deliverables.
          o     Implementation Director – The Implementation Director will provide guidance regarding the
                use of KFS. She will review all configuration spreadsheets.
          o     Project Manager - The Project Manager will provide guidance regarding the storage and
                maintenance of documents, will develop an approach to monitor configuration progress, and
                will provide guidance on various project standards.
          o     Module Lead – responsible for the overall configuration of the module, and ensuring that
                configuration is occurring and that the module is responding accordingly
          o     Functional Lead – responsible for ensuring the overall configuration process is being
                followed and is occurring so as to minimize business impact at the time that KFS is
                implemented in place of FRS.

5    Tactics
    5.1       Maintain Configuration Data
Once the strategy has been agreed upon and the master reference data and parameter spreadsheets have
been set up, the functional lead will review the strategy and the spreadsheets with the BSAs to ensure they
understand how each of the workbooks/worksheets should be completed, where they should be stored,
etc.

Reference tables are used to drive the available values for many of the attributes that are associated with
the different business objects, such as accounts, object codes, requisitions, etc. Each module in Kuali
comes with a set of reference tables and there are also reference tables for the system as a whole. Until
Kuali goes into production we will maintain the values of these tables in spreadsheets so that we can
continuously reload reference tables from the spreadsheets. “Master” workbooks will be set up for each
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


module and assigned to a BSA for maintenance, while the system-wide reference tables will be
maintained by the Parameter Coordinator. Changes to a specific module’s workbook will be the
responsibility of the members of that module, and will likely be assigned to be the responsibility of just
one person for that module. Each module lead will be responsible for determining how their module will
handle this process, be it by one designee, or by each member of the module team. Changes to the
system-wide parameters will be requested to the Parameter Coordinator, who will then make the change
and communicate out the change to all of the BSAs and KFS team leads, and, depending on the phase,
potentially to others, such as testers. This will help to ensure that those who might be impacted by the
change will be in the know and will better be able to determine whether a change might have had an
adverse impact on testing or assert that the change might be inappropriate given other knowledge.

Parameters in Kuali are used to control several aspects of the software, from file sizes allowed on
attachments to the number of records that will display in results list to allowable object codes on
transactional eDocs.

Much like reference tables, each module in Kuali is delivered with a set of parameters. Additionally there
are parameters for the system as a whole. Until Kuali goes into production, the parameter values will be
maintained in spreadsheets so that the values can be reloaded when necessary. During data loads the
parameter tables remain unchanged. This is to ensure referential integrity within Kuali, allowing for the
appropriate data validations to occur if they are built into a process (e.g. if a value were to be removed in
the middle of a load, it might invalidate some of the data that was loaded that included that value).

The Parameter Coordinator will work with each module’s BSA to review and update parameters. If BSAs
discover they need to make changes to their parameters, they will work with the Parameter Coordinator to
ensure the changes are made in Kuali. Much like the maintenance and reference tables, this will follow
the process of first being performed in the test environment, and then added to the configuration
environment after being fully tested. The full process is discussed in 5.2 below.

The Parameter master spreadsheet should contain the delivered values; UA values and the date changes
will be made so that changes can be backed out if something doesn’t work as expected, or if it is found to
have a negative impact on another process.


    5.2       How this process will take place . . . in actuality
Most of the environments will be refreshed periodically, at specified intervals. As part of the refresh
process, the functional configuration process will be repeated to initialize the environments as appropriate
for the purposes of that environment. For more information on the environment strategy, refer to the
Environment Strategy document located at P:\Shared\Kuali Financial Systems_KFS\00 Proj
Mngt\Strategy\Environment Strategy vX.X (where X.X represents the version number of the document,
which was 1.2 as of this publication).

Additionally, depending on the purpose of the environment, additional configurations may occur. The
following indicates the list of environments, per the environment strategy document.

              Demo
              Development
              Configuration
              Conversion
              Test
              Staging
              Training
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


           Production
           Support

The following will ID an environment, and the process that will be followed to configure that
environment. It should be noted that any refresh of an environment will include the most current
configuration data available for the various automated loads (conversion, spreadsheet upload, or database
migration). It is assumed that all environments will be periodically refreshed with the most current
configuration data, unless otherwise specified. This process will involve either leveraging a copy of the
configuration data from the Configuration environment being used as a basis for the new environment
(database migration), or will involve automated conversions of certain configurations, such as reference
data, as well as spreadsheet uploads of certain configurations, such as parameters. Any refreshes of
configuration data via the conversion process or via the spreadsheet upload process, whether scheduled or
ad hoc, will result in the loss of all data in that configuration data set for that environment, and a
replacement with whatever exists in the database migration, conversion or spreadsheet data set.

Any references to updating configuration values assume that the Parameter Coordinator is making
changes for parameter updates, including the updates to the environments, to the Parameter log, and to the
Parameter master spreadsheet, and that the appropriate BSA is making changes for reference values for
their module, including updates to the environments, to the corresponding spreadsheet log and to the
master spreadsheet for that reference value.

Environment: Demo
The demo environment will be a Kuali Financial System with nothing but the KFS base code and will
have some delivered demonstration data. Initially this environment is not intended to receive any of the
University of Arizona configuration information. It instead will have the Kuali Foundation configuration,
as well as sample transactional information from the Kuali Foundation. It is possible that parametric
changes may be made to this environment to validate some functional capabilities, but they will not be
entered into the Parameter tracking spreadsheet unless they are implemented in the Test environment.

Environment: Development
The development environment is used by the development team. As such, they have initially indicated
that they do not need to have the configuration data laid down into their environment. They may, at
times, load configuration data to support some of their testing, but they do not have a strategy initially to
load the full configuration.

In the event that any development requires a new configuration value in order to prove out the
development efforts, the development team will coordinate the effort with the appropriate BSA team
(based on module) to see if a configuration will resolve the issue. The BSA will manually update the
configuration in that environment and will note as such in the configuration log document for that
module, be it for a parameter, or for a reference value. If it is found that the configuration change
resolves the issue, the configuration will be manually entered into the Test environment as well and run
through some transactional tests to validate that it is not having an adverse impact on other transactional
testing.

If the configuration change is found to be appropriate for both environments, it will be added to the list of
values for that parameter or reference field.

If the configuration change is found to be unnecessary, the log will be updated to indicate that it was not
necessary and no changes will be made to the list of values for that parameter or reference field.

Environment: Configuration
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


The configuration environment will follow the standard refresh process. As additional configuration
values are found to be necessary and proven via testing, the configuration log will be updated as
appropriate, and the value added to the appropriate worksheet for the parameter or reference value. After
that has occurred, the value will be manually added to the configuration environment by the same
resource that added it to the Test environment. The configuration environment is intended to represent
only the configuration values that have been proven via testing. It is not meant to have any transactional
data entered to validate the configurations, conversions, etc.

This environment is not intended to be refreshed with regard to the configuration data.

Environment: Conversion
The conversion environment will follow the standard refresh process. As this environment is used for
testing conversions, it will be important to ensure that this environment is updated with the latest
configurations to ensure that the configurations properly enable the converted data to be transacted to the
extent that it is intended.

As conversion testing is taking place, if it is deemed that a configuration value is needed in order to
enable a converted value to be used appropriately, the conversion team may request the assistance of the
appropriate BSA team (based on module) to see if a configuration will resolve the issue. The BSA will
manually update the configuration in that environment and will note as such in the configuration log
document for that module, be it for a parameter, or for a reference value. If it is found that the
configuration change resolves the issue, the configuration will be manually entered into the Test
environment as well and run through some transactional tests to validate that it is not having an adverse
impact on other transactional testing.

If the configuration change is found to be appropriate for both environments (Conversion and Test), it
will be added to the list of values for that parameter or reference field.

If the configuration change is found to be unnecessary or is found to not be acceptable for the Test
environment, the log will be updated to indicate that it was not necessary and no changes will be made to
the list of values for that parameter or reference field.

Environment: Test
The configuration environment will follow the standard refresh process. As testing is performed and if it
is deemed that a new configuration value is needed in order to enable a transaction to be processed
appropriately, the testing team may request the assistance of the appropriate BSA team (based on module,
and it will often be themselves) to see if a configuration will resolve the issue. The BSA will manually
update the configuration in that environment and will note as such in the configuration log document for
that module, be it for a parameter, or for a reference value.

If the configuration change is found to be appropriate for the test environment, it will be added to the list
of values for that parameter or reference field. It should then be part of future refreshes for all
environments.

If the configuration change is found to be unnecessary, the log will be updated to indicate that it was not
necessary and no changes will be made to the list of values for that parameter or reference field. The
value in the Test environment will be removed either manually, or via the next refresh of configuration
values.

Environment: Stage
The Stage environment will be configured only by the automated process of configuration, unless it is
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


deemed necessary to perform additional manual configurations as part of the “move to Production”
process. At this point, it is not expected that any manual configurations will be performed in the actual
move to Production. As such, Stage and Train are expected to be built and configured in a manner
consistent with Production so as to allow for repeated testing of this process.

Environment: Train
The Train environment will be configured only by the automated process of configuration, unless it is
deemed necessary to perform additional manual configurations as part of the “move to Production”
process. At this point, it is not expected that any manual configurations will be performed in the actual
move to Production. As such, Stage and Train are expected to be built and configured in a manner
consistent with Production so as to allow for repeated testing of this process.

Environment: Production
The Production environment will be configured only by the automated process of configuration, unless it
is deemed necessary to perform additional manual configurations as part of the “move to Production”
process. At this point, it is not expected that any manual configurations will be performed in the actual
move to Production.

Environment: Support
The Support environment will be a hot mirror of Production, and will therefore be created via the
mirroring process and should not require configuration as it will inherit its configuration from Production.

    5.3     Validation of Parameters and Maintenance/Reference information
BSAs will review their master spreadsheets for completion, adding tabs for missing reference tables even
if the data is not changing from the delivered values. These may not be readily evident to the BSAs but
will be added as they become aware. The determination of completeness will be derived out of testing
(e.g. the need to add new values) and will be highly dependent on the BSAs’ rigor that they follow in
making updates to the spreadsheets as changes are discovered. As major changes occur, the spreadsheets
will be reloaded first to a configuration verification environment to validate that the change to the
spreadsheet took effect, and then to the appropriate testing environment(s) to ensure that the change had
the anticipated effect on the business process. The environments to which the changes should be applied
would include the conversion testing environment, the configuration testing environment, the migration
verification environment, and the quality assurance environment . . . all on the premise that eventually the
changes will be part of the migration to the Production environment.

It is important to maintain the log sheet within the appropriate workbook, listing the reference tables that
have been changed so that only those spreadsheets will need to be uploaded if a selective refresh is
performed. Uploading spreadsheets will be coordinated with the Data Conversion team, as well as with
the Environment team.
    5.4     Load the master spreadsheets
BSAs will coordinate with the Data Conversion team to upload data from spreadsheets into the
configuration environment. As configurations have been verified in testing, the configuration process
will be re-performed in each of the other environments as they are re-built per the environment strategy.
Periodic refreshes will be performed and will include the additional values that have been deemed
appropriate at the various stages of the project, such as BSA review, configuration testing, conversion
testing, development/unit testing, system testing, user acceptance testing, etc. This will be part of the
environment strategy.
    5.5     Configuration verification
For those areas where a conversion is being performed from FRS or where a spreadsheet is being loaded,
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


BSA’s will validate the resulting data first for completeness. Either through SQL queries, FRS searches,
FRS inquiries or by other means, BSAs will determine the number of rows of data that were to be inserted
to the database from either FRS or the source spreadsheet. This may require some assistance for the
technical team, but should be minimal. The BSAs will then perform similar inquiries on the KFS
database to validate that the number of rows added to the database reconciles to the number expected.

The BSAs will then perform sample checks for accuracy. Some of these checks will be made via query
(possibly requiring assistance of the technical team again), while others will be made by retrieving
information in Kuali and looking at the data there. Much of the accuracy issues will be found this way,
although it is also anticipated that we may find further issues through our testing.

This verification process will occur for the Configuration environment, the Testing environment, the
Train environment, the Stage environment, and the Production environment, as these are the
environments that will be used functionally and need to be validated for completeness and accuracy for
subsequent transaction purposes.
    5.6     Workflow and Departmental Reference data
Up to this point, the tactical section has only discussed the methods by which the reference/maintenance
tables and parameters would be maintained. The scope of this document also includes the configuration
management for Workflow. As of this document’s creation, it is anticipated that there will be
communication with the departments and units to allow them to gather information related to their
departments’ workflow. The designees for the departments and units will then participate in a training
session so that they know how to configure their workflow. The plan is to then have those users then log
into a testing environment and perform their departmental or unit configurations. They will be requested
to perform some minimal testing to validate that the values they entered are appropriately being reflected
in the routing of the related workflow objects.

Upon confirmation that the workflow is reacting appropriately, the workflow tables will then be exported
to a spreadsheet for future upload into the other environments. Any references to uploading spreadsheets,
extracting data, or data format in this section, as well as for the rest of the document, will require the
assistance of the development team.

Departments will also complete templates to have their specific reference values loaded, such as sub-
account. These templates will be made such that the data can be uploaded, or, if the department prefers,
they may manually enter this data so that they are familiarizing themselves with the process that they will
be responsible for in the future.

Each department will be asked to sign a confirmation of load that will represent their consent that the
workflow and reference tables appear to be appropriate. A challenge of this approach, depending on
when this process is executed, will be ensuring that the data is up-to-date when the move to production
occurs. As an example, if departments and units configure their values 2 months prior to go live, and
people change roles between the time that they configure their values and the time that the KFS system
goes into Production, the data within the system may be out of alignment with what it really should be
from an organizational perspective. At some point in the project prior to the implementation date, a
freeze will be implemented on changes to the configuration data. Any changes that are required after that
freeze date will follow the normal maintenance process defined for the Production environment and will
be the responsibility of the requesting area to keep track of the necessary changes and create the necessary
request for those value updates in Production.

Departments will be responsible for maintaining a list of these changes and will either need to
communicate the changes to the project team, or will need to accumulate a list of the changes and submit
Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


the changes upon system implementation.

      5.7    Approvals
Periodically throughout the project the Business Process Owners and Business Process Advisors will be
required to sign off on documentation indicating their approval of the proposed information. For
configuration, signoffs will be obtained from the BPOs and BPAs relative to the parameters that fall
within their modules and will be explained to them by the BSAs.

Additionally, the departments and units will be asked to sign an approval form indicating that their values
appear to have been appropriately loaded/entered into the KFS system, and that their workflow approvals
appear to be in the system and reacting as expected for the various transactions.



6     Factors
6.1       Concurrent Projects
              Project team members should be cognizant of other projects that might affect resource
              availability. Also, other projects may be performing similar process analysis of which the
              KFS Implementation project might be able to take advantage.

              Other projects currently underway at the University of Arizona:
                 o Implementation of PeopleSoft HCM
                 o Implementation of PeopleSoft Student
                 o Implementation of Kuali Coeus
                 o Lean Six-Sigma Process Reviews

7     Strategy Roadmap
      7.1    High Level Timeline – Still in flux
      o     Master Spreadsheets for each module – 2/28/2009
      o     Parameter Spreadsheet for the application – 2/28/2009
      o     Data load complete – 3/15/2009

      7.2    Progress Monitoring
A spreadsheet tracking the status of each module’s reference tables and parameters will be maintained.
This spreadsheet will be in one of 4 status values – Not Started, In Progress, Firm, and Complete. A
spreadsheet will only be marked In Progress once it has been established and contains some of the values
expected. Before then, it will be considered Not Started. Once testing is well under way, as it appears
that values are stable, a spreadsheet may be moved to a Firm status. The final status of Complete will
only be assigned when the BPOs and BPAs have given their approval of the User Acceptance
Environment.
      7.3    Training
An informal training session will be conducted with the BSAs to go over the approach for the system-
wide and module-specific configuration, and to discuss the configuration plan and the methods in which
the configurable values will be maintained and propagated in accordance with the information presented
in the rest of this document.

When it comes time for the departments to configure their workflow routings, it is likely that the

Document1

                                              The University of Arizona
KFS Implementation – Configuration Strategy                               10/26/2011 4:27:06 AM


departments will undergo a training effort on how to perform their configurations, with the BSA team
performing some validations of the data to ensure that departments appear to be performing the
configuration, and that the configuration that they are doing appears to be capturing their flows
appropriately. Lab sessions will be offered to the departments to allow them to come in and configure
and validate their configurations.

In the early phases of testing, the BSA team will likely create some bogus routings to begin with to
validate that the routing appears to be working correctly before inviting the departments to perform any of
that configuration. At this time, it has not been determined how the departmental workflows will be
carried forward from environment to environment, nor is it known if we will attempt to capture this
information in spreadsheets.
    7.4     Move to Production
As mentioned earlier, this strategy lays out the general structure that is the underpinning of configuration.
As we become more comfortable with our process of configuring environments and further solidify the
steps to configuration, those steps will translate directly to how the resulting configurations will be
migrated to the Production environment. The final configuration process, including conversions,
spreadsheet uploads, and/or manual conversion steps will play an integral part in the move to production
process, and will include the same verification process followed in other environments before releasing
the system to the general end user population.
    7.5     Signoff
Signoffs will be obtained from the Business Process Owners (BPOs) at various intervals. Most of them
will come in the form of emails indicating that it appears that the system contains the appropriate
configurations. These signoffs should be incorporated into the testing strategy and are intended to be
signoffs of the system as a whole, including configuration, and not just of configuration itself.

If project management deems it appropriate, signoffs can also be obtained on the configuration
spreadsheets, but to date the values contained therein do not appear conducive to presenting to a person
who is not overly familiar with the configuration process, and will likely result in more time and effort
than walking the BPOs through the system testing process, articulating the configurations along the way
to facilitate the overall signoff.
    7.6     Document Management
As of the creation of this document, all documents related to configuration will be stored on the project
shared drive within the following folder structure:
P:\Shared\Kuali Financial Systems_KFS\97 Data Conversion
Other document management solutions are currently being evaluated for the project as a whole and may
prove beneficial for configuration management as well. If another solution is deemed more appropriate,
this document should be updated to reflect the change in direction, but it will be published to the project
as a whole regardless of whether this individual document is updated.




Document1

                                              The University of Arizona

								
To top