A pre study for selecting a supplier relationship management tool

A Pre-study For Selecting a Supplier Relationship
Management Tool
Stockholm 2014-10-28
1

Summary (1-4)
2
• This pre-study was performed by a team of a Business Architect, a
project manager, other experts and stakeholders from the Business
Unit X.
• The architecture point of view is dominating in this pre-study.
According to the Business Architect “the author of this pre-study”,
the main tasks of a Business/IT architect is to provide a cost efficient
and accurate solution that is according to the business requirements
and aligned with the business and IT strategies and constraints.
• The Business Architect as well as the project manager are
responsible to identify, communicate, manage architecture and
project challenges and risks, and at the same time pave the way for
the key stakeholders (e.g. the sponsor) to make the right decisions.

Summary (2-4)
• The goal of this short pre-study is to:
• Create prerequisites and basis for making a decision regarding selecting
a suitable solution for managing Suppliers in Business Unit X. The
decision maker is the sponsor for the pre-study.
• Achieve consensus among the involved stakeholders regarding the
requirements and selecting a suitable tool for the business unit.
• The business requirements (see pages about: Constraints, Use Cases, Quality
Attributes) are gathered and analysed against the available tools in the
enterprise and outside the enterprise.
One of the main outcomes of the pre-study is: The business requirements
and constraints are not implemented by the available tools in the
Enterprise. This leads to evaluate new Supplier Relationship Management
(SRM) Tools that satisfies the business and implements the business
requirements.
3

Summary (3-4)
• The time to market issue was a very critical element to determine the
selected tool. According to the time schedule, the plan for the delivery of
the SRM system is during the next 6 months. Creating an on premise
internally hosted solution will take much longer time comparing with an
public Cloud/SAAS solution.
• Other important issues and criteria were:
• The available functional capabilities in the tool
• Security requirements including the IT security
• Alignment to the business requirements and the target architecture for
the solution domain
• The flexibility, and the cost of the tool
• The interoperability capability of the tool
4

Summary (4-4)
• The circumstances in previous page, have impacted the direction of the
solution. The team suggests the following recommendation:
1. The team recommends using an available cloud solution in the market:
Microsoft Dynamics CRM Online 201X with minimum customisation.
2. The business Unit X should start with planning and implementing a pilot
project for evaluating the usability and fitness for purpose for above
tool for the team Y.
3. The business Unit X should evaluate the pilot project and the lessons
learned from this project and make a decision if the tool is suitable to be
rolled out to the rest of the Business Unit X and recommend the tool to
other Business Units in the organisation.
5

The Pre-study
• It is a very interesting and challenging
assignment to plan and run a pre-study, at
least for me.
• Interacting: interviewing, planning and
running workshops with different
stakeholders is a worthwhile work.
• As an Business and IT architect you need to
analyse different aspects of the suggested
architecture.
• As an architect you need to consider and
analyse at least 9 aspect of your
architecture, more information in pages 30-
32.
• The above is required in order to get a
comprehensive view of the as-is and the to-be
situation of your architecture
Build your decisions based on
facts not on assumptions!
• Find dependencies, challenges and risks.
• Support the business to make the right
decisions in their investments. 6

The Pre-study Method
It doesn't matter whether a cat is white or black, as long as it catches mice. Deng Xiaoping
• There are of course many available methods that could be
used to achieve goals and objectives in an assignment or a
project.
• The main principle here is to keep it simple and to use a
method that is recognized and previously used by you and
the involved team that you work with.
• The method used in this document is based on PDCA (Plan,
Do, Check and Act) method. We use this method as high-level
method to plan the assignment (project), gather and
agree about requirements, and identify, design the
alternative solutions and act if there are any gaps between
the requirements and the outcomes of the pre-study. The
PDCA cycle is widely used in industry, lines of business to
improve processes and as a tool for problem solving.
• You may need to add milestones or check points to the
method in order to control and monitor the progress and
the achievement of the goals in your assignment.
7

PDCA and a Lean Approach
Begin with the end in mind. Stephen Covey
• Using a lean approach with the PDCA method:
- In the beginning, the analysed solutions are still
hypothesis.
- The hypothesis need to be analysed and checked
against the requirements and other constraints in
order to make a short list of solutions.
- Using the recommended solution for one team and
check if the tool is applicable for the team.
- If the tool is not applicable then the Business Unit will
continue to seek after a suitable tool according to the
PDCA cycle.
- If the tool is applicable then other aspects need to be
considered.
- The Business Unit needs to start implementing the
tool in a teams in the organization.
- The lessons learned from every implementation will
be considered in the next implementation. 8

The Pre-study Method - The Architecture Approach (1-4)
• As we mentioned, we decided to have an architecture approach to recommend an
accurate architecture and solution for our costumer.
• The architecture approach is based on the following disciplines:
- Guiding Principles
- Requirements Management
- Solution Selection
9

The Pre-study Method - The Architecture Approach (2-4)
• Quality will be ensured by performing an architecture and security review for the main
delivery: The recommended solution. This part is not included in this pre-study.
• Taking right architecture decisions requires that various factors are in place. One of
these factors are:
- Business engagement/ business sponsorship
10

The Pre-study Method – The Architecture Approach (3-4)
There are three constants in life... change, choice and principles. Stephen Covey
In a high-level an architecture approach is based on:
1. Identifying the needs, analysing the problems and translating these needs to business
requirements (in a high level).
2. Constraints need to be defined (e.g. guiding principles, finance/budget and resources,
legacy systems and systems of records, the baseline of the company, etc). These
constraints can impact the architecture solution.
11

The Pre-study Method – The Architecture Approach (4-4)
3. In my experience (20 years in IT sector and more than 10 years working as business and
IT architect) you can rarely provide a right solution in the first time. Conceptualisation and
providing different alternative solutions is a right way to discuss, assess and agree about a
right solution.
4. To achieve an accurate solution for a specific capability (e.g. SRM) you need to analyse
the architecture from different (9) aspects in order to be sure that you are implementing
the right solution.
12

The Pre-study Method
1.I added the stakeholder and stakeholders’ needs as a new
component in the center of the PDCA method. The main
task of a project manager is to:
- Ensure the satisfaction of the project’s stakeholders.
The main task of an architect is to:
- Ensure a proper translation of the stakeholders’ needs to
understandable requirements in order to provide an
accurate delivery (solution).
2.Plans will start with scoping the goal, objectives and
requirements on the solution. Do not forget the risks and
challenges.
3.Do according to the plan.
4.Check if there are some gaps between the required
outcomes and the actual results.
5.We may need to take more actions to correct the result and
act if the solution is applicable for the rest of the
organization.
13

The steps for implementing the pre-study
The only thing that's constant is change. “Heraclitus”.
The steps to achieve the agreed goal for this pre-study are the following:
1. Identify the stakeholders that need to be engaged in this pre-study and analyse
their concerns and needs. Involve the right stakeholder at the right time. Arrange
meetings and workshops with your stakeholders.
2. Plan:
1. Start with a problem description. Define what is the purpose, benefits and
the needs for obtaining a tool (in this case for supplier relationship
management) in BU X (what kind of problems will be solved by this tool).
2. Define the required efforts and the work packages (Work Breakdown
Structure). Identify the required resources (users, requirement manager,
architects,…). Identify and manage the risks and the challenges.
3. Define the most important use cases (functional requirements) and the
quality attributes (non-functional requirements) that is important for the
key stakeholders (users,…).
4. Define the key criteria for evaluation of the solutions
14

The steps for implementing the pre-study
3. Do:
1. Define the main solution alternatives according to business requirements.
2. Compare the defined alternatives according to the agreed key criteria and
select the best alternative to go forward with.
3. Present recommendation and the outcomes of the pre-study to the
sponsor and other stakeholders.
4. Check:
1. Require feedback from the key stakeholders and check if the
recommended solution is according to the business expectations (
requirements, constraints).
2. Run a pilot for the recommended solution.
5. Act:
1. Adjust, improve (if needed) and decide if the solution is applicable for the
organisation.
2. Create prerequisites to rollout the solution in the rest of the business unit.
15

1. Manage/Engage Stakeholders
Some main principles for managing your stakeholders:
• If you have many stakeholders and if there are risks for conflicts
between different interests, concerns and expectations, then you
may need to analyze your stakeholders’ power and influence in your
assignment.
• Clarify and meet their expectations.
• At the end of the day you might not satisfy all your
stakeholders. The key stakeholders with the most power and
influence are very important to concentrate on.
• Identifying stakeholders is not an easy task.
• Face to face meeting with stakeholders is a good way to obtain and
gather their concerns. A good way to obtain commitment is to
actively engage your stakeholders.
• You need to build trust with your stakeholders.
16

1. Manage/Engage Stakeholders
• The question here will be: Who are the key stakeholders for the
required tool?
• Another question is: How you will work with your stakeholders in
order to meet their expectations?
• The next 4 pages lists the key stakeholders, their concerns and what
kind of Deliverables/Views need to be provided for every
stakeholder.
• The Deliverables/Views need to be agreed between the stakeholders
and the providers (in this case the project manager and the
business/IT architect).
• A suggestion of how to communicate with every stakeholder should
be presented.
• It is very important to keep your stakeholders informed and you may
need to have regular meetings with them in order to present the
status and require a decision from these stakeholders.
17

1. Key Stakeholders (Business Part)
Stakeholder Concerns
The Sponsor of the pre-study
• Achieving the desired business benefits
• Cost efficient tool and a project within time boundaries
• According to the business requirements
Users in the Team Y
within BU X
• Easy to use tool
• Configurable and adaptable tool to organisation’s and
user’s needs
Process Owner,
Information Owner and
business architect
• Adaptable to the agreed process
• Contains the information required by the organisation
• Ensure the alignment to the business/IT strategy and the
Target Architecture of the domain
Project Portfolio Owner,
IT Demand Organisation,
Project Management
Organisation
• Budget, project plan, resource management
• Manage/update the portfolio
• According to the business requirements
Business Security Office • Ensure a secure Information management, especially in a
Cloud environments
18

1. Key Stakeholders (other parts)
Stakeholder Concerns
The Enterprise Procurement
Organisation
• Involvement in the pre-study in order to reach an
agreement with the supplier of the tool
The Supply Organisation (internal:
including the IT architects)
• Ensure the right delivery of the solution from the
external supplier
The Supply Organisation (external
including IT Operation)
• Ensure the alignment between the delivery and
the business requirements
IT Security Office • Ensure a secure Information management,
especially in a SAAS environments
Enterprise Architects • Reuse enterprise standard solution before buy
• Application consolidation and complexity in the
IT landscape
• The solution should be according to the Target
Architecture of this area (domain)
19

2.1 Problem Description
20
The first question that you need to ask yourself as an architect or a project manager is: Do
we rely need a pre-study or a project or an advanced tool for solving the business problems?
Why the business users cannot continue with the current way or use Excel to perform their
supplier management activities?
Our stakeholders are the start point and to understand their needs.
Now when the stakeholders are identified and the their concerns are analysed, we need to
go more deeply in the problem description in order to understand the background of the
initiative.
The following problem description is based on needs from one of the main Stakeholder:
Team Y within the Business Unit X.
When a new project with a procurement and supplier interactions activities starts then the
project:
• Do not know what experiences with the available suppliers the business already have.
• Have no idea with whom the business worked together in the past.
• There is no information available for the projects about the contact persons from the
business side for a specific supplier and the contact person from the supplier side.
• The information about the suppliers is not searchable and is not accessible by different
channels (e.g. Web, Mobile).

21
This leads to:
• Missed opportunities for frame contracts with suppliers.
• Low transparency for projects regarding existing contracts /
suppliers.
• Time consuming to find companies/suppliers relevant for a required
service from the business.
• Every project contacts suppliers individually. This leads to complains
by suppliers.

22
The baseline (the current solution):
• The current solution implemented in BU X, has been used for about
3-4 years now and this solution is based on the current Document
Management System. The solution reached the level of being utterly
unmanageable.
• Currently the Team Y within BU X have a “data dump” in the current
Document Management System with about X00 companies which is
a nightmare to manage or “search” through.
• The current solution does not satisfy the business needs

2.1 Objective and Business Benefits
23
Objectives:
• Create a searchable supplier relationship information repository for
contacts, contracts and assessments of different suppliers in the BU X.
• Create a strategic advantage via engaged and trusted suppliers and
partners.
Benefits of Supplier Relationship Management:
• Minimize supplier-related risks
• Maximize opportunities to reduce/avoid costs
• Capitalize on potential synergies revealed through greater integration
between the supplier and the business
• Maximize user (business) satisfaction (comparing with the current
solution)

2.2 Work Breakdown Structure
24
"Nothing can exist without order. Nothing can occur without
chaos." Albert Einstein
• The following figure
is a simple
presentation of a
WBS for required
efforts to
accomplish the
task.

2.3 Business Contraints
1. Time Constraints: The time factor is very important in order to improve
the business performance and user/customer satisfaction. According to
the suggested time plan for the delivery of the Supplier Relationship
System (SRM), the system must be delivered during the next 6 months.
2. Financial Constraints: The budget allocation for this project is X00€.
3. Ambition Level: The ambition level of the business is to establish a cost
effective solution for a (SRM) system.
4. Security Constraints: See page number 52-53.
5. Maturity and Social constraints: The maturity of SRM tool and the
maturity of organisation to work with a new SRM tool (business
readiness).
25

2.3 IT Contraints
As we mentioned previously, the solution should apply the guiding
(architecture) principles provided by the enterprise.
The main applied Policies and Principles (Architecture Constraints) in the
enterprise are:
1. Reuse before buy, buy before build: The application consolidation in
the company is forcing the IT organisation and the business to think
many times before obtaining a new product.
2. (Re)using standards can improve quality and provide lower costs of
the Solutions. But standard selection needs to be handled carefully.
They should not become a barrier to business enablement and
innovation.
3. Alignment to the agreed business and IT Target Architecture. The
recommended/selected solution should be aligned and checked if it
is in line with the defined Target Architecture (if a Target
Architecture for this area is provided).
26

2.3 IT Challenges and Contraints
IT Security Constraints:
1. Information Access: ”Managing identities and access control
for enterprise applications remains one of the greatest
challenges facing IT today”, according to research from the
Cloud Security Alliance [1].
2. Moving the information outside the country or the
Continental: Regulations require business to keep sensitive
data within the country or the Continental. Although keeping
data within the country or Europe borders seems like a
relatively simple task on its face but the cloud vendors will
often not make that guarantee.
IT readiness: the readiness of the supplier (especially the internal
IT Supplier) for managing a SRM Tool. This constraint includes the
available competence and available resources to develop and
maintain the selected solution.
27

2.3 Business Requirements:
• The stakeholders are identified and their concerns are analysed, and
we went more deeply in the problem description. Now the time is
arrived to translate these problems and needs into an
understandable requirements.
• As a Business Architect you need to be involved in providing the
business requirements and ensure these requirements will be
understandable by IT provider.
• As an IT architect or a solution architect you need to understand the
business requirements in order to recommend the right solution to
the business.
• As an IT architect you may need to involve the developers in a very
early stage to ensure the feasibility, alignment and the accuracy of
the provided solution.
28
Time spent in reconnaissance is seldom wasted. John Marsden

2.3 Business Requirements:
• It is important to gather and analyse the
requirements and work together with
the business and IT to make the
requirements more specified and
understandable for the IT supplier and
other stakeholders.
• The business requirements should be
described first in high-level.
• Map the requirements to a business
capability (if the enterprise uses a
business capability map).
• The business capabilities should contain
the baseline systems that are currently
used by the enterprise and the target
system that will used in the future.
• In the business capability map view we
can see what are the current and the
future standards and here we can start
to select the available solutions.
29

The 9 aspects of a Business and IT Architecture
• Achieving coherence in
30
Business/IT Architecture
is a very important task
for the business and IT
architects.
• The architects should be
responsible for analysing
the impacts of different
aspects in the provided
solution.
• In my projects, I analyse
the presented 9 aspects
on the solution that I or
other architects provide.
• Here you can also analyse
the impact of the new
solution in the business
and the IT environment.
This part is not in the
scope of this work.

Here is a description of the 9 aspects of the business and IT
architecture applied for our SRM Case:
1. The SRM Tool could be used in different organisations and this
means changes in these organisations. The project may need to
manage these changes during the project’s (or a programme’s)
life cycle, starting with a pilot.
2. A Project could be related and dependent on other ongoing
projects in organisation and the target architecture of this
domain. The project need to interoperate and cooperate with
these projects/ initiatives in order to move to the same
direction.
3. The SRM processes may need to be harmonized (to a certain
level: if needed) in the organisation. A smaller number of
process variants lowers the cost of business process
maintenance and increases the agility towards process changes.
4. The SRM information definitions may need to be harmonised
too in the organisation.
31

5. The project will manage the business requirements for the involved stakeholders and
organizations. The business requirements are divided between use case (the functional
requirements) and the Quality attributes. The Quality attributes (non-functional
requirements) are very important aspect for the IT architecture. The project will gather,
analyse and balance the most important business requirements.
6. For the application part the SRM Tool should provide the required processes,
information and capabilities according to the business requirements.
7. The SRM Tool needs to interoperate with other systems in order to exchange
information with these systems.
8. The infrastructure will contain the needed components to host the SRM Tool
processes, capabilities and data.
9. The result of the all above aspect is:
• Solution or (alternative solutions)
• A capability or an updated capability that has:
– own challenges, risks
– Views and models
The architects provides recommendations and at the end of the day, the business
(sponsor) need to take a decision about how to go forward.
32

Some Basic Recommendations
• Lean implementation is preferred
• Establish a joint team (Business Representatives, Architects from
different levels, IT/Supplier, users other stakeholders).
• Plan and conduct workshops and meetings and strive to have
alignment and commitment.
• Document and communicate with the stakeholders (especially
with the sponsor and the users) in order to:
• Manage their concerns and needs/Requirements.
• Provide the status, and discuss risks and challenges.
• Require decisions and a way forward.
• Prioritise between requirements if needed.
• Start with a pilot.
• Do not sped a lot of time in detailing and specifying the
requirements if that is not necessary.
33

2.3 Business Requirements: High-level
• As a business architect you recognise the urgent business need of
an Supplier Relationship Management Tool for the business unit X.
• Supplier relationship management (SRM) is the discipline of
strategically planning for, and managing, all interactions with third
party organizations that supply goods and/or services to an
organization in order to maximize the value of those interactions.
In practice, SRM entails creating closer, more collaborative
relationships with key suppliers in order to uncover and realize
new value and reduce risk [2].
34

2.3 Business Requirements: High-level
As a business architect you need to check how the business is performing
the SRM activities today and get more understanding about the pain points.
• As You see, the pain points
are in every step of today’s
way of working with
suppliers in the current
used tool by the BU X.
Some of these pain points
are:
1. Managing the not trusted
data.
2. Provide poor quality
reports.
3. Receive Information about
the Supplier and Select
Supplier according to
unreliable information. 35

2.3 Use Cases And Quality Attributes
36
Poor requirements management is a major cause of project failure, second only to changing
organization priorities. Source: PMI 2013 Pulse of the Profession®
• A list of the most important use cases and quality attributes is attached in
appendix 1.
• The analysis of the use cases and the quality attributes shows:
• The business requirements are applicable for many usual CRM/SRM
tools provided by different vendors in the market (e.g. Microsoft and
Salesforce).
• The use cases “UC11” states: The BU X, as well as all operational and
strategic procurement staff have to have a default access through single-sign-
on. Provide possibility to add additional users (e.g. externals).
• The quality attribute requirement “QA4.1” desires: Compliance to data
protection laws (EU and local laws)
• As you see, these requirements need to be further analysed for security
reasons.
• In order to go forward with analysing the above requirements, we need
to specify the information (security) requirements.

2.3 Information Requirements
• A good way to identify
the required information
is to list and structure the
information objects.
• The presented
conceptual model
describes the main
information objects in
the context of the SRM
system.
• Of course the system will
include more entities and
these need to be listed
too.
37

2.3 Information Requirements
• One of the main benefits of gathering, analysing and structuring the information is to
check the information security requirements. This will help to conclude if there are
some highly classified information/confidential information that will be managed
within the business processes and exchanged between different systems. This view
will help the solution providers to design and implement a security architecture
according to the information security requirements.
• Another benefit is to check if the tool is implementing the required information in a
right way. To some certain level, the information should be mapped to the data
presented (implemented) by the tool/system.
• We also can use the information requirements for integration purposes. In this activity
we include:
• Information definition and information structuring/modelling
• Master Source management
• Interfacing and exchanging the information between the sources of the
information
• Integration solution for exchanging the information
38

2.4 Evaluation Criteria (1-2)
• The following Evaluation Criteria were agreed with the Stakeholders.
• It is very important to determine the criteria weight in a multi-criteria decision
making.
Criteria Description
Costs Costs for different alternative solutions and even cost implications
of not moving to a new solution (e.g. keeping the current Solution)
Fitness For use and purpose
Solution (meet the business
needs)
Implementation of the business needs by the available and
potential tools. The business needs will be translated and
described in an understandable requirements: Quality Attributes
and Use Cases.
According to enterprise’s
policies and principles
The solution should consider and implement the enterprise’s
policies and principles. In case of exceptions the project need to
motivate why an enterprise’s policy or principle is not applicable
for the project.
Duration (Delivery time/Time
To Market)
In this case the time when the business will obtains the alternative
solution. This could a very critical criteria with regards to the
current situation and user/customer satisfaction.
39

2.4 Evaluation Criteria (2-2)
Criteria Description
Reusability The reusability factor measures the ability to obtain a solution within
the Enterprise landscape. This could be a strategic and target solution
or a solution that is based on a current available systems in the
Enterprise.
Business
Impact
The impact (risks, complexity “process changes”, business readiness
“organisational changes and training”) of the tool/solution in the
business.
Complexity Selection of an alternative solution could impact the IT-landscape by
providing an additional complexity (in case of developing or buying a
new solution or customizing a current solution).
Maintenance,
Support and
Skills
Different alternative solutions need different types of support and
maintenance and skills. These parameters need to be considered
when we evaluate an alternative solution.
40

3.1 Alternative Solutions
As IT Architect you need to:
• Scan the company and the company’s application repository to find
possible alternative solutions
• Check the on-going and future initiatives/projects that are aimed to
obtain the required capability. You may need to ask and check different
project portfolio in different Business Units
• Use the company’s capability map or a standard list for recommended
systems and applications (if any).
• Scan the available products in the market.
• Make a list of possible alternative solutions.
• Evaluate the list and try to make a short list of alternative solutions.
• Present the short list (not more that 4 alternatives) for the business in
order to ensure the right alternatives are selected.
41

The following are the possible alternative solutions that can be
provided :
1. Alternative 1: The future common Enterprise Solution: The
Enterprise Supplier Portal. This solution is not defined yet and it
will be based on the target architecture of this domain
(CRM/SRM). This is a long-term solution.
2. Alternative 2: The current standard solution (reusing the
Enterprise Solution/Service). This is a short-term solution. The
solution will be replaced by alternative 1 in the future.
3. Alternative 3: Using/obtaining a new application/Service - (SAAS)
solution.
4. Alternative 4: Business as usual (continue with Business Unit
Document Management based Solution). This is not an option and
will not be evaluated.
42

3.1 Alternative 1: Common Enterprise SRM
• The solution is a long-term solution and is depending on other capabilities in the
enterprise (e.g. BI, CRM, PPM, Interoperability).
• The solution will be a part of an integrated solution that involves different capabilities.
• The business unit X may need to wait until the target architecture for SRM is defined and
the solution is provided.
• The colours in the
following picture
represents
Gartner’s Pace
Layers view of
systems, see the
next page.
• I added a white
colour for the
capabilities/sub
capabilities that
do not have any
target systems.

3.1 Alternative 1: Common Enterprise SRM
•In a report, Bill Swanton of Gartner [14], defined Systems of Differentiation as:
•“the applications, or parts of applications, that deliver unique and differentiating
capabilities that distinguish the enterprise from its competitors and are not readily available
on the packaged software market.” (Gartner, “Systems of Differentiation: Building
Applications that Provide Competitive Advantage”, Bill Swanton, August 2012).
• According to [15], Gartner
sees Systems of Differentiation
as arguably the most critical
part of the Gartner Pace
Layered Application Strategy as
compared to Systems of Record
that are typical served by ERP
systems for well-understood
business processes that change
infrequently.

3.1 Alternative 1: Advantages and Disadvantages
Criteria Advanteges Disadvanteges
Costs Common budget for the
Enterprise
Solution (meet the business needs)
Common Processes for
supplier management,
The scope is too wide for BU X
Duration (Delivery time) Not specified : +1 year
(delivery).
Reusability The solution will be based on
the Target Architecture
Complexity No additional complexity
Business Impact Common Tool and common
training.
High business impacts.
According to enterprise’s policies
and principles
Yes
Maintenance, Support and Skills Common Maintenance,
Support
45

Criteria Advantages Disadvantages
Costs High costs
Used by many Business
Units in the Enterprise.
needs)
• Many business requirements are
not applicable by the tool.
• Not a part of the target
architecture
Duration (Delivery time) Short implementation time Need for migration when the the
target system is in place.
Reusability Used by many Business
Units in the Enterprise.
Complexity Complex system
Maintenance, Support and
Skills
Supported by internal IT
Business Impact Available training material Need for training.
Yes
46

3.1 Alternative 3: Using/Obtaining a New Solution
This alternative is valuable when:
• The business requirement do not match the capabilities in the current
systems that are available in the Enterprise. In this case the business has
the opportunity to obtain a service or a solution outside of the Enterprise.
• The target system is not in place and the business needs a temporary
solution during this time.
• The main consideration is the application consolidation. Consolidation describes
the desire to minimize the number of assets that deliver similar functionality.
• A very strong business case/motivation needed to justify and get agreement
and decision to buy a new solution.
• Cooperation with the capability owners (owners of SRM) in order to include
their requirements and select and pilot the future tool.
47

3.1 Alternative 3: A New Solution
• The architects with support from other experts scanned the market for a suitable
Proposed solution based on MS Dynamics
• Dynamic folder structure
• Standardised supplier information
• Set high level of data quality
• Searchable with keywords and queries
• Easy to use for anyone with basic training in IT solution
48

solution for the business unit X
• Many tools were downloaded, analysed and presented to the users in the Team Y
within BU X
• MS Dynamics xRM concept were very promising and gave the team y a good impression

• The solution could be a long-term solution if the stakeholders are satisfied with the pilot
and the roll-out and if the system could easily integrated to other systems of records in
other related capabilities in the enterprise (e.g. BI, CRM, PPM, Interoperability).
• We can use the pilot as an experiment for defining the target architecture for the SRM
capability.
• The colours in the
following picture
represents
Gartner’s Pace
Layers view of
systems, see the
next page.
• I added a red
colour for
indicating that we
have a pilot in this
area.

• The pilot will create a solution for the following sub capabilities (capability level 2):
- Supplier Management
- Contract Management
- Contact Management
• The solution will be a part
of systems of innovation
according to Gartner’s
Pace-Layered Application
Strategy.
• The solution could be
used to differentiate the
business and drive
innovation in the business
unit and maybe in the rest
of the enterprise where
the needs for such
capabilities are required.

Criteria Advantages Disadvantages
Costs Low
needs)
On of the tools has the best
match to the requirements
The scope and the requirements
could be increased if other parts of
business units X will be involved
Duration (Delivery time) Possibility to match the required
time table
Resource allocation and Availability
of resources
Reusability Possibility to reuse the
applications by other parts in the
enterprise
Complexity Easy to use and obtain Adds a new software to the
existing applications in the
Enterprise
Maintenance, Support and Skills Based on a available technology
in the market
External resources are needed to
support and maintain the new
application
Business Impact Available training material Need for training.
According to enterprise’s policies
and principles
Yes The security part need to be
investigated
51

• The following table describes the evaluation of different alternatives.
• Alternative 3 had the most acceptance from the main stakeholders (the users).
• As we mentioned in the beginning, our job is to get consensus among all involved
stakeholders including the Business and the IT Security Office
Criteria Alternative 1 Alternative 2 Alternative 3
Costs Not known High Low
needs)
Should be (in the future) No According to the business
requirements
Duration (Delivery time) Long-term solution Low Low
Reusability Yes No Possible for usability
within other units
Complexity Not known Highly complex Easy to learn and adapt
Maintenance, Support and
Not known On premises On premises or in the
Skills
Cloud
Business Impact Not known High Low
Should be (in the future) Yes The security part need to
be investigated
52

Alternative 3a And 3 b
As we mentioned in the previous page, the solution
could be deployed inside the enterprise or as a Cloud
solution. For alternative 3, there are at least two
main variants:
• Alternative 3 a is based on MS Dynamics 2013 in
an on premise solution.
• Cloud solution based on MS Dynamics 2013
Online (alternative 3 b).
53

Alternative 3a And 3b
Advantages 3a:
• Alternative 3 a is the most secure from an
enterprises point of view.
Disadvantages
• To develop and deliver this application
inside the enterprise requires many efforts
from internal and external resources.
• As we mentioned previously the time to
market issue is very important parameter
for the business.
Advantages 3b:
• To develop and deliver this
54
application in the Could will not
require many efforts from internal
and external resources.
Disadvantages:
• Alternative 3 b requires security
analysis.

Security Requirements
• One of the main challenges and risks in this project was associated with
security requirements and how the supplier (in this case the provider of
the Cloud solution) will guarantee the required security level (e.g. do not
make the information available to other agencies).
• According to the information requirements analysis, we concluded that the
tool will handle some high classified information/confidential information
(e.g. supplier information, user authentications “from the enterprise’s
Active Directory”).
• For these two issues the project decided to:
1. Allow the procurement office in the enterprise to discuss an
agreement with provider of the Cloud solution that guarantee the
required security level. This issue is out the scope of the pre-study.
2. Gather an IT security expert group from the enterprise and the
Cloud solution provider in order to agree about a suitable
solution, see the next pages.
•The IT security expert group started a short pre-study to design a solution
according to the security requirements.
55

More Detailed Security Requirements
The following security requirements have been used as input to the solution:
• Managed, centralized, vendor supported solution.
• Support of secure transfer protocols such as SFTP and HTTPS with possibility to use
certificates and encryption techniques.
• Several layers of security, there can not be a single point of failure.
• Scalable solution, a basic framework that can be reused again and again for new
scenarios / applications without building each implementation from scratch.
• Dynamic, not locked to a certain provider or technology for identity store,
authentication method or messaging standard.
• Integration also with applications outside the realm of enterprise’s Active Directory
(or other identity stores) must be seamless for the user and support all types of
integration that is uses within enterprise’s own AD realm. Most notable here is
single sign on between applications.
56

Security Requirements
• The solution boils down to analyse two
issues that are presented in the
following schematic diagrams:
1. How to protect and not make the
Suppliers’ and User’s information/data
and even other data available to any
authority that required the
information? How to get guarantee for
that from the Cloud solution provider?
This issue is leaved to the procurement
office. This part is also related to the
location of the Cloud servers (in
Europe or somewhere else). In an
international company you need to
consider different regulatory
requirements on sending confidential
data outside the country or the
continental.
2. How to provide a seamless and secure
user access control according to the
provided security 57 requirements?

Security Solution
After analysing the security requirements, the security experts recommended to:
• Consider the Target architecture for the enterprise regarding the movement to the
Cloud solutions and Cloud Providers.
• If the possible scenario is to obtain a Cloud solutions, then experts recommend using a
standard tool in the market.
• The MS Dynamics 2013 Online solution combined with Microsoft Azure Active
Directory Access Services ACS will be tested in the recommended pilot project to
check if the designed security architecture implements the business security
requirements.
• The experts recommend to analyse the impacts of Microsoft Azure Active Directory
Access Services ACS in the enterprise’s IT landscape and create the prerequisites to
connect to the available services from Microsoft.
• A short description about how Microsoft Azure Active Directory Access Services ACS
provides seamless and secure user access control is presented in the next page.
58

ACS Authentication (1-2)
According to [13], ACS is built on the principles of claims-based identity. To complete the tasks we
should understand the following terms and concepts:
Client - A browser that is attempting to gain access to your web application.
Relying party (RP) application - Your web app. An RP application is a website or service that outsources
authentication to one external authority. In identity jargon, we say that the RP trusts that authority.
Token - A user gains access to an RP application by presenting a valid token that was issued by an
authority that the RP application trusts. A collection of security data that is issued when a client is
authenticated. It contains a set of claims, which are attributes of the authenticated user, such as a
user's name or age, or an identifier for a user role. A token is digitally signed so its issuer can be
identified and its content cannot be changed.
Identity Provider (IP) - An authority that authenticates user identities and issues security tokens, such
as Microsoft account (Windows Live ID), Facebook, Google, Twitter, and Active Directory. When ACS is
configured to trust an IP, it accepts and validates the tokens that the IP issues.
Federation Provider (FP) - Identity providers (IPs) have direct knowledge of users, authenticate users
by using their credentials, and issue claims about users. A Federation Provider (FP) is a different kind of
authority. Instead of authenticating users directly, the FP brokers authentication. It acts as an
intermediary between a relying party application and one or more IPs. ACS is a federation provider (FP).
ACS Rule Engine - Claims transformation rules convert the claims in tokens from trusted IPs so they can
be used by an RP. ACS includes a rule engine that applies the claims transformation rules that you
specify for your RP.
59

ACS Authentication (2-2)
The following figure shows how ACS authentication works
with a web application:
1. The client (in this case, a browser) requests a page from
the RP.
2. Since the request is not yet authenticated, the RP redirects
the user to the authority that it trusts, which is ACS. The
ACS presents the user with the choice of IPs that were
specified for this RP. The user selects the appropriate IP.
3. The client browses to the IP's authentication page, and
prompts the user to log on.
4. After the client is authenticated (for example, the identity
credentials are entered), the IP issues a security token.
5. After issuing a security token, the IP directs the client to
send the security token that the IP issued to ACS.
6. ACS validates the security token issued by the IP, inputs the
identity claims in this token into the ACS rules engine,
calculates the output identity claims, and issues a new
security token that contains these output claims.
7. ACS directs the client to send the security token that ACS
issued to the RP. The RP validates the signature on the
security token, extracts claims for use by the application
business logic, and returns the page that was originally
60 requested, [13].

The Time Plan For Implementing The Tool
61
• The high-level suggested time plan for implementing a Pilot Project and
rollout of the tool in rest of the business unit.

Costs for the Pilot
• A detailed estimation of the required efforts for establishing a pilot
project presented in the following table:
Activities Resources Hours
62
Total
hours
Project Management 1 16 16
Requirements Management 1 20 20
Solution Development including Integration and security solution 2 20 40
Workshops and meetings (Presentation and alignment) 2 8 16
System Configuration and adjustments 2 20 40
Test 2 10 20
Training, 2 including preparation and documentation 1 20 20
System Documentation 1 20 20
Handover to governance organization including setup of production
1 8 8
environment
Total 200

Risks
63
• The main risks in this pre-study are:
Risks
• Changes in the business and the IT
strategy that impacts the selected
product.
•Merge results and inputs from
different teams/users in a solution
that cannot be used for the next
team.
•Decreased value to the
users/stakeholders.
• Complex tool and high costs for
maintenance.
• The tool cannot be upgraded to the
next version because of the inserted
customisation.
• The tool will not be a part of the
enterprise’s target architecture.
Mitigations
• Ensure that the selected product is
flexible.
•Agree about the main activities and
the main information needed by the
users and the key stakeholders.
• Specify the requirement from different
stakeholders and check early if there
are conflicts in the business
requirements
• Evaluate the flexibility/modifiability in
the tool.
•Use the standard configuration as
much as possible.
•When customising the tool for specific
needs, make sure that the system will
still be robust, useful for other
stakeholders and easy to be upgraded
to the next version.

3.3 Recommendation
• As mentioned in the section about the Business and IT constraints, the time issue
is very important and according to the time schedule, the plan for the delivery of
the SRM system is in the next 6 months. The cost of the project should not
exceed X k€. The pre-study and the involved experts (from IT Demand, Solution
architects and solution experts for SRM, CRM in the organization) could not find
a suitable solution that could satisfy the customer’s needs.
• The business requirements (see page: Use Cases, Quality Attributes and available
tools) are not fully implemented by the available tools in the organization.
• Under these circumstances and to meet the business requirements, the
creators of this pre-study suggest to the business:
• To use available software as a service in the market with no customisation.
The recommended Tool is MS Dynamics CRM 201X Online.
• Start with implementing a Pilot Project according to the suggested time
plan.
• Present the recommendation to the sponsor and other stakeholders (e.g. in
steering group meeting).
My job is to make images and leave the decision-making and conclusion-drawing
to other people. “Laurie Anderson”
64

4 Check
• You and the project manager present the recommendation and the motivation
for why you recommend this solution.
• Present the risks, the estimation for the required efforts and the time plan for
delivering the pilot and the next steps.
• You need to send the pre-study to the key stakeholders in a good time in order
to give them the opportunity to go through the material.
• In the meeting with sponsor and with the other key stakeholders, require
answer from the key stakeholders about the way forward for the project.
• If the answer is yes from sponsor and from the other key stakeholders, then
create the prerequisites to run the pilot for the recommended solution.
• Support the business unit with establishing an agile team from different parts of
the enterprise:
• Business users
• Requirement manager
• Architect and solution expert
• Developers (from the supplier)
• Project manager
• Test manager 65

5 Act
• The outcomes of the pilot need to be evaluated and the experiences will be
captured and documented.
• The pilot could turn into a successful project or a disaster
• Even if the pilot turned into a disaster, then the enterprise will not lose a lot
of financial and other resources. That is the good thing with a pilot when
you compare it with a direct big bang rollout for the whole business unit or
the whole enterprise.
• The big decision is if the business “sponsor” agrees to rollout the solution to
the rest of the business unit.
• The pilot could be used as a template (may with some improvements) for
rolling out the solution in other parts of the business unit.
66

References
67
# Source
1 http://www.cloudsecurityalliance.org/guidance/csaguide-dom12-v2.10.pdf
2 http://en.wikipedia.org/wiki/Supplier_relationship_management
3 http://www.pmi.org/Knowledge-Center/Requirements-Management.aspx
4 http://www.opensecurityarchitecture.org/cms/definitions/it_security_requirements
5 http://www.opensecurityarchitecture.org/cms/definitions/it_security_requirements
6 http://www.opensecurityarchitecture.org/cms/library/patternlandscape/259-pattern-data-security
7 http://www.coramodel.com/overview/
8 http://www.opengroup.org/johannesburg2011/Ulrich%20Kalex%20-
%20Business%20Capability%20Management.pdf
9 http://msdn.microsoft.com/en-us/library/ff359101.aspx
10 http://msdn.microsoft.com/en-us/library/hh873308(v=vs.110).aspx
11 http://www.codeproject.com/Articles/290606/Claim-based-Authetication-WIF-Part
12 http://en.wikipedia.org/wiki/Cloud_computing_security
13 http://azure.microsoft.com/en-us/documentation/articles/active-directory-dotnet-how-to-use-access-control/
14 http://www.gartner.com/technology/home.jsp
15 http://www.pricing-matters.com/author/uiyervistaar-com/

Appendix 1: Requirements (Use Cases)
# Use Case Description
UC1 Add / Change
Supplier
Add change a supplier and have the ability to add
additional information to the data entry.
UC2 Add / change
Supplier History
Add historical time intervals with experiences.
UC3 Add / change
supplier contracts
Add contract we have or had in place with the supplier.
UC4 Add / change
supplier meetings
Add or and change a meeting with a supplier.
68
Poor requirements management is a major cause of project failure, second only to changing
organization priorities. Source: PMI 2013 Pulse of the Profession®
The following use cases in this and the next pages are based on needs from
the main Stakeholder: Team Y within BU X .

2.3 Use Cases
UC5 Add / change
supplier status
Status in regards to usability of the supplier like locked,
permitted, untested, contracted, deleted, etc.
UC6 Add / change
supplier risks
List of further analyses which have been done with that
supplier; e.g. Supply Chain Review, Quality Audits,
Technology Review, Risk Analysis, etc).
UC7 Analyse Supplier
Metrics
Gantt chart with contracts with the supplier. Historical
data about the interaction with supplier.
UC8 Export Supplier
Data
Have a standard template for ppt or word which, when
exported, is automatically filled with all relevant supplier
information on 2-3 slides as far as information is available
for the supplier.
UC9 Export Supplier
Data
Have a standard excel export to export all suppliers with
the basic data of the supplier tables in columns; the same
for the meetings / timelines information, etc. for
individual suppliers.
69

2.3 Use Cases
UC10 Search
supplier
Be able through a filter matrix and various fields to search suppliers
by: name, location, keywords, etc.
UC11 Admininster
Access Rights
The BU X, as well as all operational and strategic procurement staff
have to have a default access through single-sign-on.
Provide possibility to add additional users (e.g. externals)
UC12 Admininster
Access Groups
By organizational unit, all employees are part of a group; groups are
- basic (all users), procurement (people from procurement
department), project (project staff), etc.
UC13 Merge
suppliers
If suppliers merge / change names etc. then there needs to be a
possibility to merge two supplier entries into a new third entry;
while maintaining the original entries of both; the status /
possibility to update these suppliers has then to be blocked / made
impossible for anyone but the administrators.
UC14 Delete
Supplier data
Neither suppliers nor any data belonging to them shall be possible
to be deleted; all data entries can only be put on deactivated and
become invisible to anyone but the administrators or users who
filter for deleted suppliers.
70

2.3 Quality Attributes
# Quality
Attributes
Description
QA1 Availability It concerns the need of a high availability level of the
application.
QA2 Performance It concerns the need of a high performance rates of
the selected tool.
Performance In a thick client, response times below 0,5 seconds
are required; for a thin client, i.e. browser, response
times need not exceed 2 seconds
QA3 Multiple user
access rights
Need for simultaneous access to the software client
71

# Quality
Attributes
Description
QA4.1 Security Role Based Access Control
QA4.2 Security Comply to data protection laws (EU and local laws)
QA5.1 Usability The tool should be easy to access (e.g. via IE and other
browsers).
QA5.2 Usability The tool should have a user friendly and easy-to-use GUI
for both users as administrators.
QA6.1 Configurability Support for deploying multi-units (autonomous business
units) and at the same time sharing information between
these units.
QA6.2 Configurability Support for multilingual . English is a must. Other
languages are nice-to-have. Easy to add new users, user
groups, administrators.
72

# Quality
Attributes
Description
QA7 Data migration This requirements addresses the migration facility for
importing data from the existing system.
QA8 Support General Support during working hours
QA9 Operations and
administration
Operations and administration of the application.
QA10.1 Cost/License
aspects
No costs for Suppliers regarding Buying License
QA10.2 Cost/License
aspects
Service License, user license
QA11 Interoperability The interoperability of the SRM tool with used tools in
the enterprise (e.g. MS Outlook, MS BizTalk Server, SAP
ERP).
73

A pre study for selecting a supplier relationship management tool

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (11)

En vedette

En vedette (20)

Similaire à A pre study for selecting a supplier relationship management tool

Similaire à A pre study for selecting a supplier relationship management tool (20)

Dernier

Dernier (20)

A pre study for selecting a supplier relationship management tool