In my last post we began talking about The System. Just as a reminder, when I reference systems for this perspective, I am specifically referencing the technology systems, or applications organizations use to deliver services to their customers. Let us discuss a little bit about how to identify systems.
How to Identify Systems
There are few ways you can identify what systems are used in an organization:
Ask – create a relationship with your technology partners where you can either ask questions, or see if they have system architecture, or design, documentation you can review to help you understand the different technologies leveraged in the organization. Having a strong relationship with your technology partners is critical, because at the end of the day the developers are helping to make dreams and wishes a reality. Who better to gain knowledge from, than those who helped to create the reality?
Research – find existing documentation that explains the systems in play, especially if you do not have access to your technology partners easily.
Process Analysis – as you are analyzing processes, or even better yet, documenting them, you will uncover systems that are leveraged. We discussed how to document processes earlier on in Perspective 3 if you need a refresher.
Observe /Job Shadow– conduct side by sides with individuals who do the work. Observing what others are doing brings a lot of clarity. It also identifies gaps that may have been missed
Past Experience/History – if you have worked for the organization before or have worked in a different part of the organization your previous knowledge can help you put the pieces together. Also, if you have worked in a certain industry for the majority of your career you might find there are certain technologies used more consistently and that knowledge may help you uncover what may, or may not be there.
Why is Knowing Important
As stated above, depending on your job, you may not have to know the technologies in detail. However, having some common knowledge of what the systems are, and how they work is beneficial for the following reasons:
You have knowledge of what is out there already, so when it is time for potential solution recommendations you know what is currently delivering on the business needs, and what is not.
You have knowledge of how systems integrate with each other which gives you insights on complexity, or simplicity of infrastructure.
You have knowledge on where there are technological gaps and can offer options on how to fill those gaps.
You have knowledge on where data is housed, and how it is housed that deliver services to customers (more on data coming in Perspective 6).
You have knowledge on some of the common technologies used for the industry in which you work.
You have knowledge on where systems are used, and if there are opportunities to leverage those systems in other parts of the organization.
You have a more granular understanding of the engine(s) that are behind the processes and if they are producing the optimal performance for the best service to your customers.
You have knowledge on where there may be gaps in processes that can leverage existing systems to make the process more efficient.
These are just a couple of high-level examples of how understanding the systems architecture in an organization is powerful. Though you may not the coding, or language used to drive the system functionality, knowing the systems, and the capabilities of those systems is extremely powerful.
In my next post we will move on to Perspective 6 – The Data.