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

• Find dependencies, challenges and risks.

• Support the business to make the right

decisions in their investments. 6

Build your decisions based on

facts not on assumptions!

The Pre-study Method

• 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

It doesn't matter whether a cat is white or black, as long as it catches mice. Deng Xiaoping

PDCA and a Lean Approach

• 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

Begin with the end in mind. Stephen Covey

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)

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

There are three constants in life... change, choice and principles. Stephen Covey

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 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

The only thing that's constant is change. “Heraclitus”.

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

30

• Achieving coherence in

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



needs)

Used by many Business

Units in the Enterprise.

• 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

48

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

��

��

��

��

��

• The architects with support from other experts scanned the market for a suitable

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

Skills

Not known On premises On premises or in the

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.

54

Advantages 3b:

• To develop and deliver this

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 requirements?57

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)

59

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.

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

requested, [13].60

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

62

Activities Resources HoursTotal

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

environment1 8 8

Total 200

• A detailed estimation of the required efforts for establishing a pilot

project presented in the following table:

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 manager65

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