17
Oct
This entry is part 17 of 18 in the series Interview with Tom Marine


Then as you selected the finalists and went through more of a formal RFP process that entailed them taking data and mocking it up in their system…

TM: Yes. That’s when they quoted on the system, as well.

MM: So you had vendors quoting on how to automate your workflow, as opposed to simply how to install their code and then shoehorn existing current-state users to their system?

TM: Correct.

MM: As a function of having created the user manuals, did you then have the vendor basically rewrite or augment the manuals? Take us through that.

TM: Yes. We had additional meetings, after we chose the vendor. We had a meeting where they went through how they normally train. We said, “Well, that’s very nice. But here’s how we want you to train us.”

It was more focused, but just as intense. In other words, they had a certain number of days that they had allotted, to cover every feature. We said, “Well, we don’t want to cover every feature, because we’re never going to use these. So we want you to focus more intensely on these particular features here—based on the particular jobs that are out there.”

MM: You just introduced another little gem.

TM: Okay.

The 0.1 Percent Solution

MM: Typically, enterprise systems have 30,000 or 50,000 function points—where each function points represents basic unit of work of a software application. When organizations deploy enterprise systems, they may only activate 500 or 600 of these function points.

Moreover, a power user at any one point in the workflow or process may only use 80 to 100 of these function points. And, a typical user may only use 20 or 30 of function points.

Another way of saying that is that if you take the 500 to 700 function points, that’s less than one percent—actually, a tenth of one percent of the entire set of 50,000 function points of the application.

This disparity calls into question the inherent silliness of magic quadrants or waves from these various research firms. I mean who really cares about, “Completeness of vision” if user end up only using tenth of one percent of that so called complete vision.

And “Ability to execute” represents another bogus, hackneyed concept: If 49,000-plus function points remained unused, they represent more than just overhead or potential—unused function points just become sand in the gears of execution. Someone in the implementation and others in the maintenance process have to manage all this unused functionality. Argh!

So, Tom, by getting it right up front and in analog on-the-wall fashion, you and your team identified the needed 500 or so function points that would deliver economic value. You could then focus on the workflow and quality outputs instead of al the silliness of 49,000-plus unused function points.

Category : General | Operations | Trends | Use Case | Blog
14
Oct
This entry is part 14 of 18 in the series Interview with Tom Marine


MM: Brilliant! So then, that gave you an optimized workflow that you could visually depict—probably using pretty standard workflow diagrams. Right?

TM: Yes. Sometimes there would be a written step. Sometimes it would be a screenshot with the new data. Sometimes it would be a screenshot of a directory.

MM: So these are basically the artifacts that went into the user manuals.

TM: Correct. That’s exactly what they were. Yes.

MM: So now in the course of then developing this optimized workflow—creating it one screenshot at a time.

TM: Yes.

MM: In the course of developing these screenshots, you had the operator—the intended operator—come in and interact with you and ultimately say, “Yes. That’s what I want my screen to look like.”

TM: Partly. Remember that we really hadn’t chosen the vendor, yet at that point. There were basically mockups that were just done in Excel that showed a basic idea of what it would look like from a data standpoint. But not what it would look like visually in the application.

MM: Perfect! So you developed the wire frame or the exposed data model for that particular screen or activity?

TM: Yes.

MM: Then, how long did it take you to develop that idealized workflow model?

TM: I was trying to think about that—how we broke that down. It was nine months for the total. My guess is that it was like six months for the current workflow and three months for the optimized.


Category : Interview | Blog