In the first part of the series; we discussed how we can become unhealthily dependent on our supplier and; above all; what problems this can cause for our company.
Today; we will look at what we can do to avoid such dependence.
1. Retain ownership of process and system know-how and plans for their development
If you decide that you do not want to worry about IT and give general instructions to your IT supplier; you are on the best path to dependency. What may surprise you is that this approach often causes problems for the supplier itself; because after a while; the client's requirements begin to overlap and become entangled; and meeting new requirements becomes a major problem for the supplier.
For a company that wants to remain competitive; it is important to view IT as a tool to support; improve and measure its processes. It is not difficult to figure out how to do this; because today we have enough methodologies and standards that allow us to maintain an overview of processes and carry out effective planning:
- Enterprise Architecture – a way of describing an organization's goals; the ways in which these goals are achieved through business processes; and how these processes can be supported by technology. For more information; see the article "Don't get bogged down" by poor enterprise architecture. The two best-known approaches to enterprise architecture can be found on the websites of The Open Group and Zachmann.
- Process description – the best-known and most widely used standards are created by the Open Management Group (www.omg.org). Describing processes according to the BPMN (Business Process Model and Notation) specification allows company management to easily read and record the processes that take place in their company.
- User documentation – this does not have to be a document written by the supplier and put in a drawer to gather dust. A good approach is to shoot videos that show users how to use the application in their daily work; thus simplifying product support and training for new users. The videos are often only a few minutes long and describe everything you need to know to use the system effectively. For example; take a look at the guide to using Yammer in a research project; or the guide how to order goods from an online shop.
All standards and methodologies are accompanied by comprehensive documentation and study materials that describe each area in detail. In my experience; it is worthwhile to hire a specialist who will select the parts of the methodology that are suitable for a specific company.
If you process your know-how in a standardised form; you will not only have a tool for discussing topics that lead to company improvement; but you will also gain the certainty that you will find common ground with the vast majority of your current and potential suppliers.
If you want to change something in your processes and information flow; start by making changes in the organization of work; either at the model level or through a pilot experiment – test whether the change will bring the benefits you expect. Then calculate the benefits of the change and the costs of implementing it. If everything is as it should be; start modifying the systems; and if not; you can stop the action without any problems. When you entrust this completely to an external supplier; few people have the courage to stop a project in which we have already invested resources.
2. The data must be yours under all circumstances
The data is stored with our supplier; now we have had a falling out with them and they have told us that the data is theirs... Unfortunately; this situation is not as unusual as you might think. It does not happen often with cloud service and hosting suppliers; as people often assume; but most often with custom-developed systems; where data is stored inside a black box fully controlled by the supplier.
This is a traditional way of keeping the customer under the supplier's control. The problem can generally be solved in two ways – by directly controlling the data or by ensuring a reliable way of obtaining it in a usable format.
For example; a service for managing email contacts that we obtain by registering on our supplier's website. The first approach is to ensure that the data is replicated in our own systems; and the second is to regularly download the information stored in the supplier's systems and store it with us for "just in case".
Even in our own system; where data storage is well documented; the methodology of exporting data to a standard table; database or XML can greatly facilitate the integration of a new system. It is important to establish procedures for data extraction; verification that the export is functional; and that the format is well documented; because the critical moment when we need to retrieve the data is exactly the worst moment to discover that the export is not working or that the perfectly exported data is encoded in a format we cannot work with.
The above requirements should be verified when accepting any new functionality or changes to systems from the supplier.
3. Retain intellectual property rights to applications
Ownership of applications consists of ownership of the source code or design of the application. If we do not have control over the source code; we run the risk that when we want to change suppliers; we will find that the existing supplier owns a critical part of the code and will not be willing to provide it free of charge. We can avoid this by clearly defining ownership in the contract; stating that the code developed as a result of the requested changes is exclusively our property; or that these changes are created under a license that allows us to use and distribute them free of charge.
Even if we have secured ownership contractually; this does not mean that the supplier with whom we are about to terminate the contract will grant us access to the code. For this reason; it is highly advisable that the source control system; wiki and other documents be stored with a third party and that the partner be obliged to store the data in a specific place and at a specific time so that we have access to the current versions.
4. System integration rather than functionality expansion
Web service APIs (Application Programming Interfaces) are now a common feature in many commercial and open source applications. This means that all the features or functions available to application users are also available for use between different systems and applications.
By using protocols and standards to define this interface; these services are a unified means of communication and platform; an application written in one language or on one operating system is accessible to systems written in a completely different way. Data is transferred in a common format; such as XML or JSON; and the code bases of both systems remain completely independent.
Nowadays; every user can imagine what system integration looks like. After all; we all use web application services that are integrated with each other – for example; Google Calendar with Google Contacts and Gmail. If we decide to start using a different calendar instead of the existing one; we only need to connect it to the existing data. This method of changing systems is not possible if we have our own system; which we originally purchased only for accounting and gradually had the supplier develop a CRM module; service module; etc.
The same logic applies to integration with systems provided as a service by cloud service providers (SaaS – Software as a Service). The use of web services separates individual applications from each other; making the entire system more flexible and transparent. On the contrary; fixed links between different modules make it easier for the supplier to increase our dependence on them; increase the complexity of the code; and the flexibility of the system is equal to the least flexible part.
5. Try to minimise modifications to the standard system
Try to implement the required system with a minimum of modifications to the standard implementation. You are usually not the supplier's first customer. Try to make the most of the supplier's experience with other clients during implementation. You will likely be surprised at how much more efficiently some processes can be implemented or that certain data we previously overlooked will become our competitive advantage.
If we require major changes to the functionality of the application; this may significantly complicate the transition to new versions in the future; and any transition will be challenging in terms of development and deployment.
6. Use multiple suppliers
Try to manage the entire system design; development; deployment and operation yourself and do not leave it to the supplier. It is a good idea to separate business analysts from developers; for example. It is a good idea to have the system tested by testers who are outside the development team. They will do the work more efficiently; and the likelihood of you getting a flawless product is much greater. If another party is responsible for operation (e.g.; a cloud service provider); be sure that they will push developers to deliver a product that minimises system operation problems.
7. Specify the termination process in the contract; including penalties for the supplier
How is the termination of cooperation specified in the contract? Three months' notice; after which you stop paying and the supplier stops providing support? That is woefully inadequate.
It is necessary to specify what documentation and in what quality the supplier must provide to you; or directly to the new supplier; during the notice period. If you have secured intellectual property rights to the design; source code and other parts of the documentation mentioned in point 3; so much the better. When concluding a contract with a supplier; it is a good idea to check with the companies that came in 2nd and 3rd place what they will need if they are to take over development and maintenance from the winner.
8. Inform suppliers of future development plans
Work on a long-term partnership with your suppliers. If you regularly discuss your development plans and strategic issues with them; and not just current changes in functionality; the supplier may come up with proposals that will create a system architecture that is stable; efficient and cost-effective; not only for your current requirements; but also for future requirements. To clarify your requirements; you can use; for example; the MuSCoW method; which divides requirements into the following categories:
- Must have – must have
- Should Have – should have
- Could Have – would be nice to have
- Won't Have This Time – does not need to have at this time
9. Get ideas and opinions from other parties
Don't get stuck in one place; follow trends; look for the best approaches and practices; and keep an eye on everything. Hire a company to get a third opinion – they will evaluate your decisions from both a technical and strategic perspective. It doesn't have to be expensive. And such consultation is worthwhile because it will help you avoid mistakes. From my experience; I know of a case where a supplier forced a customer to invest several million crowns in solving a problem that he himself had caused; and a consultant found that the investment would not solve the problem at all because the problem lay elsewhere.
A consultant can help you define your strategy; create demand; evaluate options; and look at things from an unexpected angle. They can also help you audit your suppliers and ensure the best possible outcome for you. A consultant should always keep in mind that you want to be independent of a particular supplier and that you recognize the value of your know-how as a competitive advantage.
The right choice of suppliers is about risk management
I believe that after reading this article; you have a clearer idea of how to turn your suppliers into partners in your success and not become their vassal. Preventing unpleasant situations is about consistent risk management and choosing solutions that balance current requirements with future flexibility. By adhering to the above principles; you will ensure the right choice of suppliers and new systems.
