TEMPLATE_Business Needs Summary_EXAMPLE.doc 4/4/2012
EXTRACT FROM BUSINESS REQUIREMENTS DOCUMENT
K
EY
B
USINESS
N
EEDS
Business case drivers, product definition documentation, legal/regulatory, and other stated requirements or needs that must be met by the final solution are described as Key Business Needs. They should be defined as much as possible for further exploration during detailed requirements definition. These Key Business needs will define the core
application functionality.
BUSINESS NEED SUMMARY TABLE:
# Need P Concerns Current Solution Proposed Solution
1 Centralize Data Entry – basic vendor information to reduce redundant data entry and naming errors (i.e. one system enters IBM and another system enters IBM Inc .
H There could be vendors entered into some systems but not others. All systems must be synchronized on a common indicator such as Vendor ID and Vendor Name.
Each system involved in the vendor management lifecycle independently enters vendor information
Basic vendor information would be entered into 1 system. If many systems are involved, the System of Record would then pass information in the appropriate format to the appropriate systems. 2 Rule- and role-based
security and access profiles.
H Vendor information must continue to be protected equivalent or greater than the current process.
Access is granted by system access, security profiles, and vendor management rules.
Vendor information must continue to be protected equivalent or greater than the current process. 3 Workflow-based processing
to provide decision prompts, date reminders, and other automated triggering, tailored based on situation, user, etc
H Need to ensure the quality and completeness of required documentation.
There is no system managed workflow processing or built-in QA.
Use workflow „wizards‟ that launch when key dates or decisions are activated stepping user through the vendor/risk management process. 4 Risk mitigation-centric
approach to vendor management
H Vendor management is not simply Supply Chain Management or Customer Relationship Management, but must be based on risk assessment and mitigation
Risk management is the central focus, but is siloed across many services areas.
Combined a full vendor management lifecycle approach with risk management the key focus in the Assess and Management phases. 5 Risk-based Vendor
Classification
H Must allow vendor ranking and tiering by risk, volume, and LOB to organize vendors for appropriate management. 6 Capacity-based
Performance
H System response time and availability must match WFC SLAs.
Key applications are running on under performing hardware platforms
To house solution(s) on hardware platforms with performance monitoring, automatic load-balancing, and built-in scalability. 7 Interface Ease of Use H While „user friendly‟ is
difficult to conceptualize, there is no consistent look and feel across lifecycle modules
Infrequent users of some systems find the modules intimidating.
Standardize the interface with the [APPLICATION], and make workflow driving
8 Module-based comprehensive reports
H Current reports are manual or limited to basic, 1-system reporting.
Current reports are manual or limited to basic, 1-system reporting.
Develop a library of pre-defined reports available on-demand to each area through security. 9 Alignment with OCC and
corporate audit standards.
Successful completion of workflow-based processing must also ensure all audit requirements are met. 10 Automate and standardize
the current Vendor Management Process and Procedures
H
Interviews, requirements gathering, and research have identified the following high-level Desired Features. These features will be matched to Business Needs, refined, expanded, prioritized, and/or modified during the requirements gathering process, and updated prior to final release as part of the sizing effort.
FEATURES SUMMARY TABLE:
# Feature P Usability Concerns
1 The [APPLICATION] shall assign each vendor an ID number that will link vendor to a single name, and be used in all integrated systems.
H The System of Record cannot provide value without standardizing the initial entry of vendors in the independent systems without a common identifier and naming standard. While the scope is in risk-management of vendors, every vendor in every repository storing vendor information must have a common identifier linking the vendor in various systems (such as vendor ID and vendor name).
2 The [APPLICATION] shall provide role-based workflow management with a specific workflow manager workspace or interface that guides users through the various “activities” such as risk management process.
H Common processing is required to ensure all the appropriate risk-based management requirements are addressed and that they are addressed to the published standard.
2.a The [APPLICATION] workflow manager shall use wizard-like prompts that are date and/or decision activated.
H A workflow-based system will support QA and ease of use requirements, but must be flexible to allow the user accountable to make judgment decisions within a framework about the completion of the work.
2.b The [APPLICATION] workflow prompts shall provide a
recommended course of action, an option for a user-defined course of action, and an option to override the workflow action.
2.c The [APPLICATION] will also allow for user defined activities.
2.d The [APPLICATION] will allow users to track various data about each activity such as progress and status. 2.e The [APPLICATION] shall provide an
Assignment feature to allow electronic notification and tracking of cross-department assignments and responsibilities during the execution of the workflow activities.
H As other departments and individuals are involved the vendor risk management, the handoff must be tracked and within certain defined guidelines, such as times to respond, standard expectations, and responsibility to complete the requested work must be communicated.
2.f The [APPLICATION] shall include a Scheduling feature that will both calculate key processing events and allow a user defined date to provide a means to notify role-based users of the required event activity.
M Scheduling and notification of workflow upcoming workflow activities should be date range based (what is due in the next 30 days) as well as vendor based (what are all the pending activities and dates for vendor XYZ).
2.g The [APPLICATION] scheduling feature shall generate automated alerts in advance of scheduled activity dates, and escalation when dates have been missed with no response.
M
2.h The [APPLICATION] workflow shall be capable of managing activities for the entire vendor management lifecycle.
3 The [APPLICATION] will support detailed security roles to be defined by process (Use Case) and by application to ensure data access and information integrity matches that set for source systems today.
H The Security and Security Profiles in place for the existing source systems will be retained in the [APPLICATION].
4 The [APPLICATION] will allow for new Vendors to be added and approved.
H
5 The [APPLICATION] shall provide logging of the system and manual event logs as a QC-based audit trail
H A historic perspective of the vendor risk-management process will assist all groups in refining and re-engineering their processes and cycle times for a more balanced and efficient workflow.
TEMPLATE_Business Needs Summary_EXAMPLE.doc 4/4/2012 # Feature P Usability Concerns
6 The [APPLICATION] shall support document storage and retrieval of all vendor documents tied to a Vendor.
H There must be store and access functionality in either a centralized document storage repository based on the [Organization] standards or linkage into the existing document repositories by standardized vendor ID.
6.a The [APPLICATION] shall support MS Word, MS Excel, MS Visio, and PDF document types.
H
7 The [APPLICATION] shall provide direct linkage to vendor Contracts and vendor contract management information.
H It should be seamless to the end user to access documents and information related to the vendor or the risk management process from any repository or location provided they have the correct role- and rule-based security.
8 The [APPLICATION] shall provide direct linkage to vendor security plans and security-related vendor management information.
H It should be seamless to the end user to access documents and information related to the vendor or the risk management process from any repository or location provided they have the correct role- and rule-based security.
9 The [APPLICATION] shall support both Inherent Risk Assessment (allows LOB to classify, do due diligence, etc.) features and Residual Risk Assessment (BCP, ESC, IT, legal, etc.) features with the workflow processing.
H The workflow processing must support, manage, and track the cross-functional risk management activities.
10 The [APPLICATION] shall provide expandable reporting features allowing centralized rule- and role-based report access – on demand – to predefined and ad hoc reporting using the data with the
[APPLICATION].
H Access to the information maintained within the [APPLICATION] must be organized and accessible to allow all levels – executive, managerial, operational, and administrative – to understand the vendor risk management process and KRIs.
11 The [APPLICATION] shall have business rules bases on the VM Domain Policy and Policy Guidebook as well as other key published legal and regulatory guidance to ensure OCC compliance.
H Corporate audit and OCC compliance to ensure the vendor risk-based management is protecting [Organization] and its interests.
12 The [APPLICATION] must be installed on a scalable hardware platform and network with performance monitoring, load balancing, and other performance and availability requirements of a [Organization] mission critical system
H Slow response times and/or limited availability cannot allow the vendor risk management process to be interrupted.
13 The [APPLICATION] shall provide for off-line processing to prevent work stopping during unplanned system outages.
H Key users must be allowed to perform manual workflow components off-line during an unplanned outage, and synchronize – even manually – when back on line.
14 The [APPLICATION] shall provide for bulk or mass updates when key elements change.
H While it should be the system design goal to limit redundant information that crosses systems (i.e. linkage should limited to the primary unique index such as Vendor ID), any redundant information stored in both the [APPLICATION] and in the source systems should be updatable. Examples might include Vendor Manager as the key contact for a vendor or group of vendors. 15 The [APPLICATION] shall support
the ability to tie a Subsidiary Vendor to its Parent.
H The system must follow the domain rules on structuring Parent/Subsidiary vendors.
16 The [APPLICATION] must allow for robust search functionality for documents, notes, forms, and other key information.
H Users must be able to search documents and data using a variety of best practice advanced search capability.
17 The [APPLICATION] must allow printing of defined vendor profiles, schedule, workflow completed, and management reports.
H Users must be able to print key predefined documents from the system.
18 The [APPLICATION] shall include a Communications feature to allow for the consolidated tracking of external and internal telephone and e-mail communications.
M Communications regarding the execution of vendor risk management should be included in the viewable information to ensure everyone is aware of past and pending communications and the response.
# Feature P Usability Concerns
19 The [APPLICATION] shall include a Notes feature to allow for the consolidated tracking informal notes related to the vendor risk
management process.
M A notes feature with publicly viewable notes and notes restricted to being viewed only by the assigned Vendor Manager/Vendor Management Coordinator will assist in managing the workflow.
20 The [APPLICATION] shall include a Forms and Letters feature that will generate Forms and Letters to be sent to external vendors, triggered by processing events.
M The main concern around the collection of current individual systems is the complete inability to provide additional features or functionality that enhances productivity and quality for all users.
21 The [APPLICATION] shall support the [Organization] standard Document Imaging process to get a paper documents into the
[APPLICATION].
H The risk-based vendor management file must be a paperless process with all key decision-making and historical event tracking activities located within the [APPLICATION].
22 The [APPLICATION] will allow for the maintenance of users.
H
23 The [APPLICATION] will allow for the maintenance of Letter and form templates.
H
24 The [APPLICATION] will allow for the maintenance of reports.
H
25 The [APPLICATION] shall consist of at least 3 layers of user security: - Log in security
- Rule and Role-based security limiting the user to views of only vendors they have assigned management of, and - Rule and Role-based content security limiting users to only documents within the vendor file that meet their security profile
H
26 The [APPLICATION] shall support the concept of a Vendor Directory, a listing of Vendors with services provided, status (Approved, Pending, Under Review, etc.), main office location, and key contacts (vendor contact and WF vendor management contact).
H
C
RITICAL
S
UCCESS
F
ACTORS
Critical Success Factor Key Success Indicator (if
applicable) Action Steps to Assure Success
To have integrated (either build one new system or centrally integrate existing solutions) at a minimum the current functionality [KEY SYSTEMS] into a centralized system of record.
Complete Project Definition Document, work plan, and integration business requirements.
Client Acceptance process To have established a centralized
Vendor Data Entry process that provides a common Vendor ID and Vendor Name for all in-scope vendors based on a single attribute such as Tax Identification Number, allowing users to trace vendors from one system to another quickly, easily, and accurately.
Complete Project Definition Document, work plan, and integration business requirements.
Client Acceptance process
To have provided a centralized on-demand reporting repository automating key performance indicator reports currently generated either manually or through single system activities.
Complete Project Definition Document, work plan, and integration business requirements.
TEMPLATE_Business Needs Summary_EXAMPLE.doc 4/4/2012 Critical Success Factor Key Success Indicator (if
applicable) Action Steps to Assure Success
To have incorporated business rules meeting corporate audit and OCC requirements in the workflow processing.
Complete Project Definition Document, work plan, and integration business requirements.
Client Acceptance process. To have standardized the workflow
processing to the approved tools and systems within the [APPLICATION].
Complete Project Definition Document, work plan, and integration business requirements.
Client Acceptance process. To have maintained system performance
and availability within defined SLAs.
SLA reporting.
To continue to met all Service Level Agreements currently in place for the Vendor Management Domain,
Enterprise Sourcing and Contracts, and Enterprise Governance.
SLA reporting.
To have increased user satisfaction (workflow fulfillment and system response time)
Post-implementation user survey.
Inclusions (In-Scope)
The [APPLICATION] considers any system that maintains vendor information (see Vendor definition in [APPLICATION] Glossary of Terms) in scope according to the following level of impact:
1. Replace or Rebuild – The [APPLICATION] will rebuild and replace the core functionality of the following vendor repository and contract storage systems and add the additional workflow management and reporting functionality and system performance requirements:
o CONFIDENTIAL o CONFIDENTIAL
2. Integrate Data – The [APPLICATION] will develop system-to-system integration to access data fields and/or documents - either physically store in the [APPLICATION] or logically link so that the workflow manager can operate and access to documents is seamless to the end user – with the following systems:
o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL
3. Standardize Vendor – The [APPLICATION] will establish the Vendor Identification Standards to ensure common naming and identification conventions for all applications in the organization that store vendor data need to be standardized, even if the data or documents are not integrated within the [APPLICATION]. This will include: o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL o CONFIDENTIAL
Key Assumptions
Assumption DescriptionAll data storage and data processing must be installed and functional on [Organization] Production Systems.
For security reasons, there will be no data processing or storage outside of [Organization] primary systems.
Detailed security roles will be defined by process (Use Case) and by application to ensure data access and information integrity matches that set for source systems today.
The Security and Security Profiles in place for the existing source systems will be retained in the [APPLICATION].
The business and system requirements defined in support of this PDD are to define order of magnitude sizing summaries, and will not be sufficient to build.
We need to establish the high-level work effort estimates. During each iteration, detailed analysis and design work will refine the in-scope requirements to provide the detailed design specifications.
Requirements in place for existing systems form the baseline requirements for the proposed solutions.
Existing applications demonstrate what works and what needs refinement. This will be assumed as the base requirements.
Any migration of data from source systems to the target [APPLICATION] system must occur systematically with no manual processing by [Organization] employees.
The proposed solution is a productivity enhancing automation solution, and must free the end users from routine
administrative system processing functions, allowing for risk management decision-making and action taking roles.
Migration must occur between the hours of 8PM and 6AM (CST) and must be completed before the next business day.
Risk management cannot be interrupted by system maintenance and updates.
Data Driven Events and Calculated fields must be installed and functional on [Organization] Production systems.
For security reasons, there will be no data processing or storage outside of [Organization] primary systems.
The [APPLICATION] will be based on Object Oriented design concepts to compartmentalize processing into components for a low maintenance, change friendly system.
By organizing the system into a collection of components, we can build in change management and scalability. For example, all the processing and calculation business rules shall be built into a separate module used by all other modules. Changing the business rules due to environmental, legal or policy changes will be limited to one component of the [APPLICATION].
