DOMP? Methodology - Love It or Leave It!

Part II: Leave it!

Tadeu Cruz

Perhaps I should be concerned about the fact that there are professionals who have rejected the DOMP? Methodology. Professionals who have simply decided not to use any methodology for mapping, analysis, modeling, organization and process management projects and have made their documentation as undetailed as possible.

Once, at the end of a conference for more than 900 listeners, three participants came to talk to me:

- Professor, you are absolutely right in defending the use of a methodology in process improvement projects.

I asked what you use to document processes?

- Each person, there were 3 of them, wrote it down in a notebook and then transferred it to a flowchart (at the time, Bizagi didn’t exist yet).

- But we're going to seriously consider using your methodology.

Wonderful, if you need me, just call me, I said, handing over my business card (back then it was still on paper).

During these almost 40 years of DOMP? Methodology, I have sought to understand why we have had failures in business process analysis, improvement and organization projects and I have come to some very interesting conclusions. These conclusions have led me to classify failures into the following reasons or causes, if you prefer.

1. Poorly completed “As Is” phase survey.

The process analyst must follow a script, which he can create himself, to use in user interviews so as not to get lost with the questions he has to ask to document the process.

2. Lack of attention when implementing the “To Be”.

The implementation of the process that has been modeled (recreated with improvements) is another point that requires attention. Simply leaving the Process Manual in the hands of the user without any explanation or guidance is the same as setting off a time bomb. It won’t be long before the user destroys all the work done through simple ignorance. And we will be the ones to blame.

3. Failure to explain the DOMP? Methodology.

Given the amount of information provided by the methodology, there is a high risk that the mapping and modeling results will not be accepted by users. Once again, this is our fault for not explaining the DOMP? Methodology.

4. The user's unwillingness to learn.

That's right. We often find users who refuse to leave their comfort zone, that is, they refuse to stop working with something they are already used to and have to learn something new.

For all these reasons, and a few others, I wrote the text DOMP? Methodology, Love It or Leave It.

I recently had an experience related to the fourth reason.

After having almost 60 processes with ready and manualized flows, I was dismissed from the project because a user did not like the DOMP? Methodology manuals and destroyed everything that had already been done, including without taking into account the acceptance of everything that had already been accepted by other users. She preferred simply a list with work instructions for each activity, without any other information, no functional paper, no times, no technologies and resources used by the activity. Nothing.

The work she wanted, and that I refused to do, was like this:

PROCESS PHASES

? Process Start.

? Request Analysis.

? Access Release.

? Service Performance.

Phase 1: Start of the Process

Responsible: Coordinator

Activities:

1. Receive access request.

Phase 2: Request Analysis

Responsible: Authorized employee

Activities:

1. Analyze the access request;

2. Inform the requester of the authorization, but if access is not authorized;

3. Inform the requester that the authorization was denied.

Phase 3: Access release

Responsible: Coordinator

Activities:

1. Enter the access password to gain access;

2. Accompany the authorized employee.

Phase 4: Service Performance

Responsible: Authorized employee

Activities:

1. Enter;

2. Perform the authorized intervention;

Service completed?

3. Yes, Sign the visit report;

4. Leave a copy with the coordinator;

5. No, Reschedule a new visit.

A complete Frankenstein, without rhyme or reason, they mixed everything up, activity with procedures and functionals roles with positions...

Very poor documentation.

Draw your own conclusions.