VPEC-T (you umm what was that again?)
This article is about a new approach to business analysis for information systems which is already proving itself in the field. The approach covers the vital time before the technologists start working on how to change, acquire or build the system, and it shows why that time is so vital. Here you'll find a description of the heart of a new framework for thinking called VPEC-T, backed up with a mind map of a remarkable new book about it.
List of contents
I've been an information systems practitioner for several decades now. For the first few years, it was only the technology that interested me. I can't say I cared much about what the business was doing with the software I built, so long as I could stay late into the night and have a computer to myself. Because that was how it worked way back then. Days were spent coding, making test data sets, hand-calculating expected results and reading code. Nights were for testing and fixing. Sleep? Chuh! Don't make me laugh. Back in the day I was more than once stopped by the police wanting to know what I was doing, while driving home at 4 or 5 a.m.
Before long, though, I realized that businesses that paid me were doing some interesting stuff with the information processed in the systems I helped to build. My focus started to move. Then, working as a consultant let me through the doors of hotels, insurance companies, satellite launch vehicle manufacturers, international courier services... and many more. There were striking differences but
common features started to emerge:
The businesses were only interested in information (and the technology to process it) that brought value. Seems obvious, but system developers often didn't give it a thought.
The businesses imposed policies on how the information was processed; so did outside regulators in many cases. This affected the design of information systems but often these constraints were not mentioned until late in the implementation of a system. The resulting late stage changes almost invariably decreased the quality of the design and stability of the system.
The businesses only wanted to process information when certain things happened: A customer called; an order was taken; some stock started getting low. But often the computer system didn't know about these happenings until someone started processing something, and even then, to the computer and its operators, it was just data coming in or going out.
Working from business events means that the perspective changes. You look at what services are needed to handle those events across the business, instead of what this department does, what that department does and how, if at all, they communicate.