Define your "What"

Welcome to the second in a series of blog posts designed to help you understand the key steps to building a compelling business case for changing key systems or processes.

Today we are focusing on your:

 When looking at changing systems or processes it is vital that you clearly identify your “what” as this provides the basis for defining the scope of new solution and the scale of the change.

In reality this entails asking many questions such as:

What do we currently have?

In order to answer this question, it is vital that you fully understand and map your current systems and processes.

Doing this before commencing a change project will ensure that you can recognise and understand every component (no matter how big or small) and include (or positively exclude) them from the planning and selection of any replacement process or solution.

For example, what appears to be as simple and insignificant report could turn out to be an entire sub system of data that has to be managed and maintained outside of the core system in order to satisfy a legislative or quality need. Without knowing it exists or understanding the context, it is likely to get overlooked in the proposed solution.

Building a register of all inputs, outputs, reports, KPI’s and integration touchpoints including who uses them, what for, how often, how they are accessed, any selection criteria and details of any calculations will ensure that you can clearly present your needs to potential vendors (your 'as is' register).

This may seem like a huge undertaking, but doing this builds a solid foundation for selection.

Including all stakeholders in this review will spread the work load while also increasing the buy in and ownership of any replacement.

What do we want to keep?

When you have completed your initial ‘as is’ register it will become clear which (if any) elements of your existing solutions need to be retained in their current form / system.

You may not want, or it may not be possible to replace some custom built functions or solutions, so having them listed as “to be retained” ensures that everyone involved in the project understands that these elements are not being replaced and have been positively excluded from the scope of the change project.

 What do we want to replace?

When you have completed your initial ‘as is’ register it will become clear which elements of your existing solutions you want to replace.

Listing those elements as “to be replaced” ensures that everyone involved in the project understands that these elements are being replaced and have been positively included in the scope of the change project.

What do we actually want or not want?

Being able to clearly express what you want and just as importantly, what you do not want at the outset will ensure that your list of potential replacements is reduced to only the best fit solutions.

For example, if you are looking to replace your key business systems (ERP), many of the products on offer will have the same core and generic functions, but not all will provide the depth of functionality that may be required in your business or industry.

Having the clarity of the need and well defined preferences enables you to dismiss and avoid wasting effort on ill-fitting solutions or partners.

General considerations:

As well as the underlying functional and user requirements there a number of additional key considerations:

How do you want to pay for it?

·       Perpetual licence with annual maintenance fee.

·       Annual subscription

·       Monthly subscription

Consider the effect on cashflow forecasting but also the longer-term cost of ownership.

How do you want it deployed?

·       On premise

·       Multi-tenant public cloud

·       Single tenant public cloud

·       Multi-tenant private cloud

·       Single tenant private cloud

Some industries are not able to have hosted solutions or multi-tenanted deployments because they have strict rules on data security and / or the uncontrolled roll out of upgrades.

Do you want the environment fully managed by a partner?

This moves the security risk to the hosting or support provider, but will generally mean that the solution is locked down, with limited access to the underlying database and tight change controls over the deployment of additional software or the upgrades of existing solutions.

What access do you need for building local or external integrations?

If integrating to local machinery or external systems (EDI, Web or 3PL etc), you may need the ability to open specific ports or to provision FTP or drop areas for file transmission.

Do you want or need access to the underlying database?

Public cloud, multi tenanted and fully managed hosted solutions will likely be locked down restricting or denying your access to the underlying database. If access is possible, it will be tightly controlled to avoid damaging the database or making unaudited changes to the data.

In summary:

Having a clear definition of your “What”  aids the selection of a potential partner and solution by providing the basis for building an RFI (Request for Information) or an ITT (Invitation to Tender) tailored specifically to your business.

Not defining your “What” will lead to poorly defined scope and requirements, missed functions and critical elements and a longer evaluation and selection process.

If you are thinking about changing any of your systems or business processes, NMcG-Consulting can help you to clarify your “What” to aid in shortening and smoothing the selection process.

Contact us via email at [contact@nmcg-consulting.com] or via the contact us form on our website http://www.nmcg-consulting.com

.