Methods for conducting business process discovery interviews and requirements gathering
A practical guide for consultants on using active listening techniques, AI assistance, and structured questioning for process diagnostics.
Successful implementation of enterprise systems begins with a deep understanding of how the business operates in reality, not just in regulatory documents. This guide focuses on developing the consultant's practical skills in conducting diagnostic interviews during implementation preparation. You will learn how to structure dialogue, use artificial intelligence as an assistant, identify true process owners, and document hidden exceptions. Mastering these methods will allow you to create accurate diagnostic briefs that serve as a solid foundation for subsequent solution design, fit-gap analysis, and change management.
Project situation and learning objectives
The project situation involves the consultant beginning the discovery phase, where the client often provides outdated manuals or describes an idealized operational scenario. The observable learning objective is for the consultant to demonstrate the ability to facilitate the meeting, uncover the actual process steps, and document them. Using standard business process catalogs helps create a common terminology among all project participants and structure the discussion, avoiding confusion over terms.
The consultant must act as a facilitator, helping the business translate its experience into the language of requirements. When preparing for the interview, it is necessary to analyze existing documentation to avoid asking about obvious things and focus on identifying gaps between the current state and the target operating model. It is important to remember that technology is merely a tool; the business model itself dictates which processes require re-engineering before implementation begins.
Effective project governance requires that business processes be the core drivers of the implementation. They reflect the organization's needs and goals, guiding your optimization efforts. By starting with a vision for future business processes, you can focus on the activities needed to reach the goal and understand how technology can transform operations, without imposing system limitations as business rules.
Active listening and AI as an assistant
Active listening involves understanding the context and hidden motives of the interviewee. Use open-ended questions starting with 'how', 'why', or 'what happens if'. This encourages the respondent to describe the process steps in greater detail. Avoid leading questions that may distort reality. Your role is to act as a mirror reflecting what is heard, verifying understanding through paraphrasing and continuous clarification of details.
Artificial intelligence is a powerful assistant in the consultant's work during interviews. Use AI tools to transcribe the conversation and automatically extract the initial process steps from the text. This allows the consultant to avoid the distraction of detailed note-taking and fully focus on active listening, observing stakeholder reactions, and formulating probing questions to uncover hidden nuances of operational activities.
Thanks to the AI assistant, the consultant can pay more attention to assessing how users currently perform their tasks and what support needs they will have in the future. Time-to-completion should not be considered the sole metric of successful learning or adoption. Independent task quality and the level of external support required are much more indicative of how well users understand the new process.
Sources: [2]
Identifying the process owner and RACI matrix
Identifying the true process owner is a critical stage in project governance. The owner is not simply a department head, but an individual with the authority to make decisions regarding process changes, resource allocation, and who bears responsibility for the final outcomes. During the interview, it is necessary to clearly distinguish the roles of those who execute operations from those who manage changes to ensure proper implementation governance and avoid conflicts of interest.
To structure responsibility, consultants often use the RACI matrix. It is important to remember that the Accountable role means having one final accountable approver who signs off on decisions, not an interchangeable performer. If it becomes clear during the interview that multiple people claim the Accountable role for a single process, this represents a serious risk that requires escalation and resolution before system design begins.
Sources: [3]
Uncovering hidden exceptions and prioritizing requirements
Exceptions are situations where the standard process fails or requires manual intervention. During the interview, always ask: 'What do you do when a client provides incomplete data?'. Often, these operations are performed in spreadsheets, remaining outside corporate systems. Identifying such 'shadow' processes is key to forming a complete list of requirements and avoiding critical errors during the solution design phase.
The frequency, impact, and lifecycle costs of exceptions require thorough discovery to determine whether their automation is justified. There are no universal economic rules, such as 'exceptions under 5% are cheaper to handle manually'. Each case requires an individual approach. The process owner must assess the risks and make an informed decision regarding which deviations should be automated and which left for manual processing.
When prioritizing requirements using the MoSCoW method, 'Must-have' decisions must consider not only operational continuity but also mandatory obligations, safety, and unacceptable risks. The existence of a manual workaround does not inherently make a requirement optional. If manual processing creates a risk of confidential data leakage or violates regulatory requirements, such automation becomes a critical business necessity.
Defining acceptance criteria and numerical targets
During the interview, it is important to agree on success criteria for the process, which will be used during user acceptance testing (UAT). The consultant must help the process owner formulate measurable goals. This requires an open dialogue about how new technologies will impact team productivity and which metrics will indicate that automation has truly delivered the expected value to the business.
When a responsible numerical target depends on discovery results, it is necessary to clearly define the measurement method and the sample or denominator. For example, an illustrative local target might be reducing the average application processing time by 20% (where the measurement method is the total processing time of all applications divided by the total number of documents processed in a reporting month). The process owner independently chooses this acceptance threshold.
Check that acceptance comparisons point in the correct direction. Launch readiness cannot be based solely on the percentage of defects fixed. All unresolved critical defects require explicit assessment, and the process owner makes the final go/no-go decision regarding deployment. Methods help establish evidence of readiness, but they do not guarantee automatic alignment with business goals.
Sources: [3]
Intecracy Group solution context in diagnostics
Intecracy Group solutions provide a technological environment for implementing the processes uncovered during diagnostics. For example, if an interview reveals complex document approval routing and compliance requirements, the consultant might consider the Megapolis.DocNet system as a potential practice and modeling platform. This solution is designed for document and process management in corporate and regulated environments.
The UnityBase platform provides the core architecture for building enterprise systems, supporting component integration and deployment across various environments. However, during a diagnostic interview, the consultant must focus on business requirements. Aspects such as workflow permissions, immutable audit logs, data migration, and built-in best practices are requirements to verify, not existing default features unless explicitly supported by the source.
Sources: [1]
Practical exercise: Creating a diagnostic brief
The practical exercise involves conducting a simulated interview using anonymized data. The participant takes the role of the consultant, while the instructor plays the role of a department head using outdated spreadsheets. The consultant's task is to apply open-ended questions, uncover at least three hidden exceptions, and determine if the interviewee is the actual process owner capable of acting in the Accountable role.
The concrete deliverable of this exercise is a bounded diagnostic brief, a process map, and a prioritized list of requirements. Feedback criteria for peer review include: the presence of a clearly defined process owner, a description of at least two exception handling scenarios, and a correctly formulated illustrative numerical target with a defined denominator. The brief must not contain premature system configuration proposals.
To consolidate the skill, the participant must independently apply this method to another case. Once the diagnostic brief is approved by the process owner, the results are transferred to the implementation plan. The identified requirements and exceptions become the foundation for the fit-gap matrix, where standard system capabilities are compared against actual business needs. This transition helps establish evidence that subsequent solution design will be based on verified facts.
Practice checklist
- Prepare a structure of open-ended questions based on the business process catalog.
- Configure an AI assistant to transcribe and extract initial process steps.
- Identify a single Accountable process owner with decision-making authority.
- Document at least two exception handling scenarios and their lifecycle costs.
- Prioritize requirements using MoSCoW, considering safety and mandatory obligations.
- Agree on a measurement method and denominator for the illustrative target metric.
- Create a diagnostic brief without premature technical configuration proposals.
Questions and answers
What should I do if the interviewee only describes the ideal process?
Use the specification technique. Ask the respondent to recall the most difficult case from the past week or describe a situation where a client provided incorrect data. This helps shift the conversation from theory to actual practice and uncovers hidden exceptions.
Does a manual workaround make a requirement optional?
Not necessarily. While a manual workaround might ensure operational continuity, it does not automatically make a requirement a 'Should-have'. You must assess mandatory obligations, security risks, and safety before downgrading a requirement from 'Must-have'.
Who determines the numerical success metrics for the process?
Numerical metrics, such as the percentage reduction in processing time, are determined and approved exclusively by the process owner based on baseline measurements. The consultant only helps correctly formulate the calculation method, including the numerator and denominator.
Sources
Article and editorial expert contribution prepared with AI assistance; attribution authorised by the site owner.