Services for making a company’s operating path explicit.

01 Service

Process diagnostic

A short, bounded examination of how a priority flow works today, used when the leadership team does not yet agree on the constraint.

Purpose

The diagnostic exists to replace competing explanations with a shared picture. It is the right first commission when people can feel that work is slow, duplicated, or political, and cannot point to a single cause without talking over each other.

Description

Elena Drancova reads the flow as it is practiced, not only as it is written. That means a limited set of interviews, a review of the procedures and trackers the teams already keep, and a close look at a handful of recent cases, including at least one that went badly. The output is not a future-state redesign. It is an accurate current state, a friction register, and a shortlist of what is worth designing next.

Scope

• One priority flow, named in the proposal. Examples of the kind of flow this can be: a customer request from arrival to completion, a hire from approval to the first independent week, a fault from report to verified close. The actual flow is yours, and it is named before work starts.
• Interviews with up to eight people who touch that flow.
• Review of existing process documents, role descriptions, and a sample of live cases the client selects.
• One readout meeting with the people who can act on the shortlist.

The diagnostic does not redesign the operating model, select software, or produce the 90-day adoption plan. Those are separate services. If the readout shows they are needed, they are proposed afterwards, in writing.

Process

1. Confirm the flow, the decision the diagnostic must support, and who will be interviewed.
2. Read the documents and the sample cases before the interviews, so the conversations are specific.
3. Interview. Ask what happens on a normal day and what happens when the case does not fit.
4. Draft the current-state sketch and the friction register. Check load-bearing facts with the people who provided them.
5. Hold the readout. Agree the shortlist, or record the disagreement as an open point.

Deliverables

• A current-state sketch of the named flow, including the main exception paths that showed up in the cases.
• A friction register: each item states the evidence, who feels it, and whether it is a flow problem, an ownership problem, a decision problem, or an evidence problem.
• A shortlist of one to three design questions worth commissioning next, with the ones that are deliberately not recommended.
• Notes of the readout, including any point the leadership team did not agree.

Who it is for

Leadership teams who need a common picture before they spend money on a redesign. It is also the right service when a board, a co-founder, or a new operator suspects the published process is not the one in use. It is a poor use of the fee if you already agree on the flow and want it redrawn. In that case start with process architecture, and say so in the enquiry.

02 Service

Process architecture

A redesign of one or two end-to-end flows so the handoffs, the inputs, the ending, and the exceptions can be followed by someone who was not in the room when they were invented.

Purpose

Process architecture is for a flow the company depends on and can no longer run from memory. The purpose is a future-state path that names what “done” means, what must be true before work moves, and what happens when it cannot move.

Description

The work starts from an agreed current state. That state may come from a diagnostic just completed, or from a brief the client can already defend. Elena Drancova then redraws the flow with the people who will have to operate it. The design prefers a path a competent newcomer can follow over a path that only works when a particular senior person is available.

Scope

• One flow as the standard. A second flow only if the proposal names it and the fee covers it.
• Future-state steps, entry and exit criteria, and the exception paths that the current-state evidence showed were common.
• Role notes at the points where work changes hands. These are not full job descriptions.
• A decision review with the operating leaders before the design is called final.

Software configuration, form building, and training of the whole workforce are outside this service. The documents are written so an internal owner can brief their own people. If you also need the order of adoption, add the implementation sequence.

Process

1. Lock the current state and the design criteria: speed, control, clarity, or a customer promise. Criteria that conflict are written down, not averaged away.
2. Draft the future state, including at least the exceptions that already consume management time.
3. Walk the draft with the people who do the work. Change the draft where the walk-through breaks.
4. Hold the decision review. The client accepts, amends, or rejects each material change.
5. Issue the architecture pack and a list of open points that remain the client’s to decide.

Deliverables

• Future-state flow with entry criteria, exit criteria, and handoffs.
• Exception paths and the rule for when a repeated exception should change the main path.
• Role notes for each handoff.
• A short control note: where a check belongs, and where a check would only add delay.
• Open-point list.

Who it is for

Operators and leadership teams who can already name the flow. Typical moments are a service that has grown past its original founder, a regulatory or customer promise that the informal path puts at risk, or a new site that cannot copy “ask Maria” as a method. If the owner of the outcome is itself in dispute, commission the operating model alongside the architecture, or before it.

03 Service

Operating model design

A design for how the work is grouped, which outcomes have a single accountable owner, and how teams are expected to rely on each other.

Purpose

Process maps fail when the structure around them is vague. Operating model design answers a structural question: which unit owns the outcome, what it may decide without escalation, and what it must receive from another unit in order to do its work. It is not an org-chart exercise for its own sake, and it is not a headcount reduction program.

Description

Elena Drancova works from the flows that matter, not from job titles. Two teams can share a customer and still need a rule for who speaks to that customer when the case goes wrong. The design states those interaction rules in plain language. Where the current structure and the proposed structure differ, the difference is explicit so the leadership team can accept it or keep the current one on purpose.

Scope

• The part of the company named in the proposal, usually the teams that touch one or two priority flows. Not an enterprise-wide reorganization unless that is the written scope, which is rare for this practice.
• Outcome ownership, interaction rules, and the decisions that should sit with a team rather than with a founder or a general manager by default.
• A short note on what the model will make harder, not only what it will make clearer.

Process

1. Identify the outcomes the model must protect. Examples: a reliable customer answer, a clean handoff between sites, a manager who can decide a case without a founder.
2. Map where those outcomes sit today, including the informal owners.
3. Draft the ownership and interaction rules. Test them against two real cases.
4. Decision review with the people who have the authority to change roles and forums.
5. Issue the operating model note and the unresolved choices.

Deliverables

• An operating model note: how the relevant work is grouped and why.
• An ownership map for the outcomes in scope.
• Interaction rules between the teams involved.
• A list of management habits that would silently restore the old model, so they can be watched.

Who it is for

Companies adding a layer of management, opening a second location, separating founder work from operator work, or merging two teams that have both been “helping” the same customer. It is not for a firm that wants a new values poster. If the flows themselves are the unknown, start with the diagnostic.

04 Service

Decision rights and cadence

A design for the choices that keep a process alive after the workshop: who may decide, in which forum, on what evidence, and how often that evidence is actually looked at.

Purpose

A flow chart does not survive contact with a busy month unless decisions have a home. This service builds that home. It is often commissioned with process architecture. It can also stand alone when the path is roughly known and the meetings are the part that fails.

Description

The practice inventories the decisions that change the work, drops the ones that are already covered by a clear rule, and designs a forum only where a forum is needed. The aim is fewer meetings, each with a reason, a preparation standard, and a record. Measures are chosen because they would change one of those decisions. A measure that would not change a decision is not recommended, even if it is easy to count.

Scope

• Decision inventory for the flows named in the proposal.
• Forum design: purpose, membership, frequency, inputs, and the decisions that forum is allowed to close.
• A cadence calendar for a normal operating month.
• An outline of the information pack for each forum. The pack is specified, not produced every week by the practice.

Process

1. List the decisions people currently escalate, reopen, or make in private.
2. Separate rule-based decisions from decisions that need a conversation.
3. Draft forums and the evidence each one requires. Remove any forum that exists only because it already exists.
4. Test the calendar against a real month so two forums are not asking for the same people on the same morning without a reason.
5. Decision review, then issue the cadence pack.

Deliverables

• Decision inventory with the owner of each decision.
• Forum sheets and a one-month cadence calendar.
• Evidence list tied to decisions, including the measures deliberately rejected.
• A record standard: where a decision is written down so it does not have to be relitigated from memory.

Who it is for

Leadership groups who spend meetings reopening last week’s choice, and operating teams who escalate because they cannot tell what they are allowed to finish. It is also for a company that already has more dashboards than decisions. If you do not yet know which flow those meetings are supposed to serve, commission the diagnostic first.

05 Service

Implementation sequence

The order in which an agreed design should be adopted, written so the client can run it without retaining the practice as a permanent member of the team.

Purpose

A complete design adopted all at once usually becomes a partial design adopted in a panic. The sequence says what changes in the first 90 days, what waits, who inside the company is responsible for each move, and what evidence would show that the design should be stopped or altered.

Description

This service assumes a design the client has accepted, whether that design came from this practice or is already written and simply not in use. Elena Drancova does not stay to operate the process. The sequence names an internal owner for adoption. Where the client has no such person, that absence is an open point, not something the practice quietly fills.

Scope

• A 90-day sequence for the design named in the proposal.
• One pilot definition if a pilot is safer than a full switch: which cases, which team, how long, and what “continue” or “stop” will be judged on.
• Adoption risks that come from the actual design, not from a generic change checklist.
• A handover conversation and 15 business days of written questions about the documents after issue. Questions after that window need a new written scope.

The service does not include running the pilot, managing staff, or configuring tools.

Process

1. Confirm which parts of the design the client has actually accepted. Unaccepted parts are not sequenced as if they were decided.
2. Identify dependencies: what must be true before a step is fair to ask of the team.
3. Draft the 90-day sequence and the pilot, if a pilot is the honest first step.
4. Name the internal owner and the time that owner will need. If that time does not exist, say so in the document.
5. Handover meeting. Leave the open points visible.

Deliverables

• A 90-day sequence with owners inside the client company.
• Pilot definition, or a stated reason a pilot is not appropriate.
• Adoption risks and the early signs that the design is being routed around.
• Handover note, including the question window and what is out of that window.

Who it is for

Teams that have agreed a design and are about to ask people to change the way they work. It is also for a leadership group that has several process ideas and needs them in an order. It is the wrong service if the design itself is still in dispute. Settle the design in architecture or the operating model first, then sequence it.

See how these services are sold