Last night at dinner, I sat beside a systems analyst whose specialty is ERP. His real love is developing software that translates one form of energy into another. Huh??? In concept, I kind of “got” what he was talking about but mostly I nodded my head up and down and changed the topic. People like that scare and intimidate me so I’m always eager to dumb it down.
The Workflow Conversation
Speaking with him was instructive in the sense that it reminded me of my workflow roots. I remembered sitting in a room full of mechanical engineers in Detroit learning how to use a BPM suite. I remember distinctly trying to create a workflow for healthcare utilization management processes while the others in the room were using their BPMS to design the assembly of catalytic converters and anti-lock brakes. I felt very out of place and – when I meet with business systems analysts and software developers – I still do. That’s not a good thing for anyone in this day and age. I represent the kind of team member the developers and analysts ought to be trying to partner with. I shouldn’t feel like they’re talking in tongues.
Todays comment is a brief one, then. Any organization adopting workflow management and BPM tactics is strongly encouraged to develop their strategy and execution in a way that ensures BSAs and managers from operational and administrative areas are working well together and equally passionate and conversant in the approach, methods and purpose of BPM/A. Otherwise, folks, IT and operations will only continue to live on two different planets. Of course, I’m not implying that an operational manager acquire the skills of a programmer nor am I suggesting that programmers and BSAs be as well-versed as the manager in his/her operations. The right blend is about buy-in, trust, lexicon and shared-purpose. Ease of use (daily, weekly) in the software goes a long way too.