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

   VPEC-T and Business Information Systems

   Information outside ‘the system’

   So “Vee-peck-tee” it is

   The 5D lens

   The VPECT mindmap

   How can we keep the focus on the business?

   Visible effects of using VPEC-T for information systems

   VPECT: Information for technologists delivering systems

   Conflicting needs and language in information systems design

   But how does it really work out?

   Conclusion on VPEC-T

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:

Values

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.  

Policies

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.

Events

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.  

System after system in large enterprises were added to meet the needs of specific units, groups, departments or regions.  Often there was overlap, and keeping track of where information comes from, goes to and is duplicated became a significant burden and one that grew exponentially.   I know this from getting my hands dirty mapping out systems, data flows and system interfaces for clients.  I have had to prepare data models for companies wanting to rationalize all these systems, particularly during expansion and mergers.

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.

Back to the beginning of this article

Back to the home page