business

The Process of Process Automation?

thaxtonmLeave a comment

Is there a way to define the process of building process automation applications (or Workflow applications if you’re confused about which is which)?

In other words: is there a way to articulate the process of doing what is done with a product like IBM BPM/BAW, but without actually talking about just one product… What if you want to create a training class (not sales) that explains how to use any BPMS/Process Automation Platform: Pega, Appian, IBM BPM, Camunda, whatever.

As a preface: I’m talking specifically about design and modeling for execution and implementation. I’m not talking about the ten thousand foot sales deck highlighting all the wonderful characteristics of BPM, BPMS, continuous improvement, easy integrations, rules, cloud-ready, built-in AI, why this platform is the right choice, etc. Let’s assume you or your leadership have bought the product already and it’s been installed or enabled or tunneled or whatever had to get done to get to the point where the product is ready to be used by a developer.

When it comes to business process automation, there has to be some kind of consistency when we get down to how to implement a process automation solution.

And yes, we can talk about BPMN and iGraphix and BlueWorks and then drive into SIPOCs and KPIs and whatever other acronym you have or whatever else you want to talk about when it comes to process modeling and discovery. But modeling for discovery and modeling for execution and implementation are two very different things.

We have to agree on that first before we continue.

No matter how much you document an HR Onboarding process (which coincidently is every BPMS’ demo/default process, yet so many enterprises already have a massive HR solution so do we ever really implement HR Onboarding in a BPMS?), is your end-automation solution just those three activities: Create Req, Review Req, Post Req?

  • You’ve got to data marshal something, right?
  • You probably won’t just display a giant empty form with Candidate Name and Address, right? You’ll want to pull from your job posting system or HR position data or organization structure. You won’t do that inside the Human activity, right? You’ll want to do that before hand in a system activity…What does the integration look like?
  • And you might want to make integration calls between those high-level Human Activities…maybe communicate with users (email, alert, etc) or other systems (events, messages, etc)…
  • And then you have to handle exceptions in those human and system activities…
  • Implement escalation or expiration timers…
  • Handle events like CMIS or JMS
  • Oh, and just that small task of designing and organizing your business/data objects somehow…

Before you know it your high-level Create > Review > Post process flow is cluttered with intermediate nodes and exception activities and ad-hoc activities and gateways and nested objects upon objects and Boolean flags that only get used once…Where did that Create > Review > Post BPMN diagram go again? It must be around here somewhere…

So where do we start?

Obviously BPMN and discovery process models are the best place to start: you have to know what activities get you from start to finish for a given process. And you have to be on the same page as your business partners. Luckily the graphical nature of process diagrams makes this an easy win. So go ahead and import that BPMN diagram into your BPMS. It is not wasted work. But be open-minded to the fact that this flow can and should change. You won’t lose the concept of your process; you’re just going to add detail to make it executable.

So let’s make this first topic short and simple and start there: a process model.

  1. Find out who does what when
  2. Find out how the process starts and what constitutes an end-state
  3. Find out what data is needed and where does it come from

I know that seems really simple, but take this chance to gather the high-level requirements for your process. Start in Sprint 0 with just some modeling and generic object design. Always ask yourself and your team: “what are we trying to accomplish here?” Because as soon as you get into the weeds of REST calls and CSS layouts and Task Names and SLAs, you might forget that.

So after the process model, what else do you need?

I’m going to start this series with a list and adjust from there. I can’t answer this question with a single post, sorry. But we’ll see what we discover along the way.

  1. User Experience: how will users participate in the process? Are you building UX inside your BPM platform (if it supports things like IBM BPM Client-Side Human Services and Coaches) or will your application rely on External UX solutions that need to integrate with an API?
  2. Integrations: what other systems does your process application need for inputs and outputs? SoR? Messaging? What is your SOA environment like: do you have an API gateway or catalog or robust microservices? Do you need to onboard to some sort of security framework when connecting to other systems?
  3. Persistence: where does your application store data: RDBMS, noSQL? Does it need to be maintained or auditable (like WORM)? What is your process data half-life?
  4. Support & Performance: what is your throughput? Where do you log? How does Production Support work? Are your process instances recoverable?

Feel free to leave your thoughts and comments about how to tackle this first process modeling step in the Process Automation application lifecycle.

What are we trying to accomplish here?

thaxtonmLeave a comment

In one of my first roles I started working as a production support business analyst for a brand new suite of applications that sat between sales channel front office users and back office operations users.  The applications went live for a merger and obviously total chaos ensued, so most of my early application life cycle experience was very rushed/put out fires/do what needs to be done.  

But eventually the application settled into maintenance mode and we started to add brand new capabilities to the suite.  I had a good time in this new business systems consultant role because I learned a lot about the application’s highs and lows, but also about the business needs for the application.  I had a lot of good experience when it came to what worked and what traditionally didn’t work and I liked having that perspective on these new projects.

Like I’ve mentioned before, applications start with requirements gathering and go on to more and more technical design assets.  This was back in 2006 or so and Agile or Iterative development hadn’t even been brought to the table at this employer; so we were very much waterfall.  We engaged IT early to help make sure we didn’t commit to something that was totally unobtainable, but for the most part the business drove these discussions (as they should).

But when you take stakeholders with years and years of experience using legacy processes or applications and try to talk about a new way of doing things, you might run into a lot of calls and meetings that get buried in the nitty-gritty details of some very specific topics.  Like “how big should this field be” or “should this section come first or second” or the horrible “this is how it used to work/this is how it’s always worked”.

My technical side would always love to get into the weeds and start problem solving code right then and there: “well if we put these values in a look-up table and expose an admin utility we can manage this logic without additional deployments” – things like that.

But after awhile I learned to sit back and let the experienced voices talk and just listen.  And I’ve got to give a lot of credit to my manager because he knew that if I wasn’t speaking out about the problem or topic right then and there, I was thinking ahead.  And he always took a second to pause and call me out even though he already knew what I was going to ask…”What are we trying to accomplish here?“

I found myself on so many calls buried in the weeds and guts of details of problems that I always tried to bring at least myself and hopefully the larger team back up a hundred feet or higher and figure out if what we were arguing about really meant that much to the endgame.  It was about finding some perspective.

This was in no way a workaround to persistent stakeholders or stubborn management.  It was just a way to gut check the meeting and make sure everyone was on the same page.  Sometimes it work; sometimes the topic was pushed aside for more important concepts.  Other times it didn’t work at all.  Like I said, experience talks and even though I didn’t see the higher purpose doesn’t mean it didn’t exist.  But sometimes just asking the question helped me and probably a few others reestablish themselves.

On the technical side now I can get buried in code and look for immediate solutions to problems from QA or UAT.  But I always try to take a step back and make sure that we’re working with a defect or change request that will make a difference in the long run.  This has been especially important in a large organization: change can come very, very slowly.  So the decisions we make and the applications we build now need to fulfill their goals because who knows when we’ll get a chance to address a missed need down the line.

“The Business” before IT

thaxtonmLeave a comment

My first role as a consultant here in Charlotte was at a mortgage processing project for a big bank.  As a recent college grad I sadly knew absolutely nothing about mortgages nor process.  

I was able to learn both of those topics along the way but something that took me a bit longer to understand was this concept of “the business” and “IT”.

As a nerdy CS grad I thought I knew what IT was: developers and system administrators telling computers what to do and making sure the computers were running well.

But “the business” was new to me.

So apparently at most large companies (maybe medium and small ones too) there is a sometimes-hard and sometimes-soft line between people who want technology to do things (“the business”) and the people that make the technology do those things (“IT”).

For this first role[1] “the business” consisted of representatives from mortgage sales and mortgage operations management – you know, the teams of people that do the busy-work of mortgages (origination, approvals, servicing, compliance, etc).  These stakeholders would talk about more than just where fields go on web pages; we’d cover topics about how the users interact with the applications, how the legacy systems-of-record interact with the new application, how to handle gaps in the process, etc.  “The business” were the people that knew what they wanted out of the technology solution, and as a consultant it was my job to translate their needs to different types of specifications.  Sometimes I created a “Business Requirements Document (BRD)” – which was essentially a document that detailed everything these folks wanted the application to be able to do for them and their user community.  Next might be a “Functional Design Document (FDD)” – a more technical approach to requirements that covered not just what the application should do, but a little bit about how it was going to do things.  And then on “IT” side they were creating things like Architecture Specifications and Technical Design Documents.

Most of the time “the business” didn’t care about how things would work, they just wanted them to work.

It wasn’t until my next role that I settled into this middle-ground.  My role was called a “Business Systems Consultant” – always the fancy titles.

I learned to sit on calls and digest business requirements and business process needs but always have technology off to side: “how would this drop-down get populated? how often does this rule change? what is the frequency of this use case? where else can this functionality be used?”  

At the large financial services companies “the business” stakeholders weren’t always from super senior management; they were process owners and department leaders that lived the day-to-day work and were the best source for context and need.  Sometimes they were SMEs (subject-matter-experts) and sometimes they were process engineers and sometimes they were consultants fresh off the street with business case studies and prior-project experience.  “The business” normally paid for the IT work.  “The business” had to build the business case that said “if we spend $100 on this project, we’ll avoid $1,000 in regulatory fees next year” (pretty simple case).  “If we spend $100 now we’ll save $5,000 over the next 5 years in process improvement while also reducing operational risk” (slightly harder business case).  “If we spend $100 now we won’t make any more money but if we don’t, we could lose $10,000 in the future” (good luck with that).  And sometimes “the business” didn’t always get the final say.  For example if some infrastructure component was going out of vendor support, IT might have to spend $100K to move an application as-is to a new supported platform but maybe they could throw in a few small enhancements or changes to put some smiles on “the business”.

“IT” was way more than just developers and admins – we had analysts to write some of those requirements, architects to pattern and fit the application to standards, managers to assign resources and forecast costs, leads to handle hours and development plans, developers to code, infrastructure to setup environments, etc.  “IT” was just as deep and “the business”.

So I was able to appreciate this divide in large organizations but I also increasingly found myself frustrated that there was a divide in the first place.  This was post-Y2K – every knows how computers and networking and the internet work.  Don’t make “IT” such a black-box and don’t make “the business” out to be so clueless and needy.

So how do “the business” and “IT” work at other companies?  I honestly don’t really know…when I went to Big Blue I was curious to understand how an IT company ran its business and I learned a lot about sales and marketing – especially industry trends and standards and competitive drivers.  I realized that fixing “defects” in products doesn’t always make the cut for a release – just like change requests were prioritized by “the business” for the mortgage or brokerage applications I knew.  My experience has still been that business drives IT…I haven’t had a chance to work the other way around.

[1] Remember that this was around 2003 – “Lending was huge” is a major understatement.