In the analyst role in Information Technology, I learned that the most important responsibility is to gain a clear understanding of the business requirements and accurately document captured requirements and business processes to include non-system related business rules that will impact the functional logic. The goal is to gather good clear requirements that support the customer’s expectations of the software deliverable. This is best acquired through working in the business process with the user to observe each step completed to achieve a specific desired result and gain an accurate clear understanding of why the user is completing each step. This is called Genchi Genbutsu, a Toyota Production System term that suggests that in order to understand a situation you must “go and see” where the actual work is done. By doing this real time observation in the actual business process, it drives identification of business rules and requirements that the user might overlook due to repetitive practice. I also learned the importance of asking good questions when interviewing users. This is an area that I applied the 5 Why Methodology to identify the root cause of an existing problem, to identify the real requirement or additional associated requirements that must work in concert to yield a specific expected result. The 5 Why Methodology technique requires asking ‘why’ 5 times to gain visibility into the root element.
Say we are implementing a solution to correct a process problem. Before we design the solution, we must first identify the requirements for the solution. With the ‘5 Why’ process, you will ask the question ‘why’ 5 times to drill down to the real problem to solve. If the root problem is identified before the 5th why is applied, you can stop the process.
Example: We are shipping incorrect parts to our customer’s manufacturing plant. You ask our inventory team ‘why’ incorrect parts are being shipped to our customer’s plants. Inventory is pulling and confirming incorrect parts to fulfill the order. Why are they pulling and confirming incorrect parts? The order/picking ticket displays the incorrect part number and stock number. Why does the order display the incorrect part number and stock number? The ordering system is populating the incorrect part number and stock number. Why is the ordering system populating the incorrect stock number? The system is pulling part number and stock number field data from the wrong table. Why is the system pulling the part number and stock number values from the wrong table? The logic is mapped to the wrong table.
This methodology allows identification of and focus on the real problem. At this point, you may have placed focus on replacing what appeared to be a broken software when you may only need to remap the field.
Once the requirements are captured and documented by the analyst, the analyst must flush the captured requirements to confirm the requirements are complete, correct, necessary, unambiguous, verifiable and conflict free from other requirements. If this mark is missed on capturing great strong requirements then every process downstream will be negatively impacted and the Software Development Life Cycle (SDLC) process will not be seamless as designed.
My advice to all interested in becoming an analyst in Information Technology, you must encompass qualities that support working with non-technical oriented customers, technical oriented colleagues and systems/software.
Written By: Ali Robinson; Tempur Sealy Global Supply Chain IT Manager (formerly an IT Analyst)