Describe the unique characteristics of user's processes
By Bianca Scholten
During a forum discussion, an IT manager at a chemical plant said, "Those fat documents that consultants write? Nobody reads those."
A feeling of "You talkin' to me?" crept over me.
As an MES and vertical integration specialist, I churn out those "fat documents" regularly. I speak with the board, the managers, and the users of the new manufacturing execution system (MES) they will purchase.
In interviews, they tell me what they expect from the new system and how it should provide advantages. I turn these findings into a user requirements specification (URS) that easily contains a hundred pages.
For many end users, maybe a document like this does end up at the bottom of a drawer somewhere. However, my colleagues who have to build the system and use it repeatedly are always very happy to have it. The better we describe the client's processes and needs, the easier it is for my colleagues to ensure the system meets them. Ultimately, it increases the likelihood they will deliver a suitable system and the client will be satisfied.
That IT manager's comment has prompted me to explicitly describe to clients, at the start of a URS trajectory, why the document is important. "You all might not use it," I say, "but the vendor has to have an extremely good understanding of what's involved here. That's why I describe the unique characteristics of your processes. In selecting a package, we can then check whether the solution is a good fit for your company. And then the system integrator will use the document as a basis for realizing the solution."
I also gave this explanation at a research company where I conducted an extensive study into the desired MES functionality in various departments. The users of the future system were highly educated people, so it was particularly important, in order to have them accept the new MES, that everyone could put in his two cents' worth. When the document was finally finished and accepted, we were able to start selecting a vendor.
"So," I commented in a conversation with the internal project leader, "now the document's going to prove its worth, because the vendors will be getting solid information about your processes and desires and requirements, and they can make a proposal that meets them."
"Yeah," he answered, "you keep saying that the URS is particularly useful to the vendor that's going to provide the solution. However, in my experience, it's also an important document for us internally. We didn't go through the whole specification trajectory that we just completed purely to provide the future vendor with information. The project has also particularly helped us to come to internal agreement about what we want. As a result of all the interviews and workshops you conducted, we've gained clarity on all the functionality the system needs to have. And on what the fundamental purpose of the system is."
This client opened my eyes. The URS is not just a document that specifies the user's processes, desires, and requirements so the vendor knows what is expected of him. It also records the decisions to which the internal parties have jointly agreed. The URS is final once the stakeholders have signed their names to it.
Contents of the URS
So one of the purposes of the URS is to provide the vendor with sufficiently detailed information about the company and about the desires and needs for the MES.
However, exactly what information does a vendor need in order to make a proposal?
When I first started writing user requirements for MES, I used the ISA95 standard as a guideline. ISA95 did turn out to be a useful starting point, but the scope of the standard is broader than MES, and conversely, a URS should contain more information than just the subjects covered by ISA95.
Within the ISA95 & MES Competence Center at TASK24, we decided to conduct a study on best practices for writing a URS for an MES.
Our analysis showed that most authors of URS documents seem to have a clear picture of its purpose. Nevertheless, when comparing URS documents written by different authors (even authors within the same company), there appear to be huge differences in scope, content, and level of detail.
We decided to develop a URS template based on best practices, so we would have a guideline to help our customers write high-quality URS documents. The template we developed is also a big help for MES vendors' sales teams.
Using it as a checklist, they are able to decide whether the information the customer has provided is complete and of sufficient quality to be able to make a proposal.
ABOUT THE AUTHOR
Bianca Scholten (email@example.com) is a partner at systems integrator firm TASK24 in The Netherlands. She is a voting member of the ISA95 committee. Her new book is MES Guide for Executives, ISA Press, 2009 (www.isa.org/link/MES_Scholten_bk) .