If we were to cite a single overwhelming challenge in becoming a commercial powerhouse, it would end up being expressed by something along the lines that what we have in terms of solution-set requires a paradigm shift in thinking before any paradigm shift in operational actions can come about.
Basically, we are in the unenviable position that we are too small to get the message out to a broad enough audience in a short enough time to generate the momentum that comes from a sudden grasp of the opportunities found in risk-management. Perhaps worse, we are trapped in a cycle where momentum is regularly drained by having to redirect limited educational resources toward operational imperatives. When starting a process with a new client has to be deferred to help an existing client find some way to aggregate data from their clumsy information systems, the limitation on our internal resources shows.
If we were a Google-size company, the reality would be different, because scale actually does drive adoption – we would be able to educate through multiple points of contact, on an immediate broad scale, and draw on the necessary commercialisation resources to create buy-in prior to deployment, rather than running these simultaneously and inefficiently. Infrastructure is key to mass adoption and capitalising on a massive untapped revenue stream.
The related problem with this paradigm shifting is that unlike many such shifts, this is a discrete two-stage shift: not only do we need to shift the thinking of the client, but we need to shift their understanding of technical tools. We need them to recognise the serious problems of existing information sources, commit to changing those to better meet their needs, and at the same time commit to using the new tools correctly.
Somewhere in our development we ran into a real conundrum related to dependent systems. We found, for example, that almost no one with a Human Resources (HR) system manages to keep it updated since it tends to be overly complex, and those who do cannot ever get data back from it in a reasonable timeframe. This meant that for our tools to work right, we needed to frequently ask them about why their current tools were hampering them. Try shifting tool use to a new and more powerful level in the face of statements like, “We can’t get a list of employees from our HR system.” Invariably the statement is true just because it actually means, “We don’t know how and no one will show us without extra costs.”
We can be as smart as we wish, we discovered, and even develop the three-step plan toward making the shift to risk-management, but ultimately size hampers adoption. It is very easy to say:
1. View your “safety” as a by-product of normal operational management;
2. View your information systems as a service-points; and
3. Rectify problems with any uncooperative systems before proceeding with the new approach.
Now, try applying those three simple steps when after step one, the overwhelming number of information systems they already depend upon can’t even reliably generate the same list twice. When our tools are deployed, and we hear that our miniscule nod to Human Resources profiling exceeds the value of the enormous system they spent millions on (since from our end they get out what they put in and more), there are obvious barriers to managing step three forward. Abandoning the sixteen million dollar HR system that hasn’t worked right in years is seldom an option, even if it is obviously a barrier to efficiency unrelated to anything to do with risk-management.
Pushing this back in the cycle exposes our main challenge, of course, and HR provides us the perfect example. We have over one hundred various requests to enhance and expand our HR profile model, almost all beginning with statements along the line, “if it just did this we wouldn’t need our old HR system at all.” Try being a gnat in terms of resource scale (or something smaller than a gnat), and hearing that, knowing full well there is no way you can expand fast enough to meet those requests without crippling your ability to deliver what you already have.
To shift someone to risk-management, away from traditional safety, isn’t so much costly as it is complex by virtue of dependencies. Often the first request we make stymies adoption for months, which is, “give us a basic employee list.” The second one, “tell us what their occupations are” invariably slams the process into reverse for a while when clients discover they simply can’t fulfil that demand from any system they have online.
Of course, if we had the scale to educate ahead of the deployment curve, expand to encompass the minor variations that prevent just replacing antiquated systems wholesale, and the reach to attack multiple client targets simultaneously this two-shift process would become a single longer curve.
No comments:
Post a Comment