/Tag: Joe Freeflier

Explaining Capability Modeling to Business Process Professionals

By |2011-08-19T11:53:05+00:00August 19th, 2011|Enterprise Architecture|

As I’ve noted in prior posts, many hard working business process management professionals find the concept of “Business Capabilities” to be confusing at best, and counterproductive at worst.  In a recent article in BPTrends, Paul Harmon made the following statement:

the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.

This confusion is well known to me.  Within Microsoft, we have a very strong group of senior professionals who base their efforts and practices on BPM concepts.  This includes Kaplan and Norton’s Balanced Scorecards, as well as methods like Six Sigma, Lean manufacturing, and Total Quality Management. 

BPM is my world too.  As readers of my blog know, I am fortunate enough to consider myself to be a follower of these same ideas, having been exposed to TQM while I was working at IBM almost 20 years ago.  I’ve worked at many levels of process improvement. 

  • At the business level: I’ve worked to convey the need for process improvement and help the stakeholders feel comfortable with methods,
  • At the modeler level: I’ve worked to collect the ideas of stakeholders and map out both current state and future state,
  • At the analysis level: I’ve worked to take models and analyze them for opportunities, target waste, and develop innovative alternatives, and
  • At the technical level: I’ve implemented a number of BPM systems and even wrote one of my own. 


That experience lets me have a good relationship with both my EA peers and my BPM peers.  I’m aware of both approaches, having done both.  As my readers may also know, I use business capability models in my daily work.  I create models of capabilities that are useful, valuable, and understandable.   I know the value of capability modeling.

When I talk about business capabilities with my peers, I have to be careful.  Business capabilities are poorly explained and poorly socialized.  It can be tough to convince a BPM professional to listen to these “radical” ideas when we, the community of architects and analysts who also use business capabilities, have communicated so inconsistently about them.

First off, let’s look at the environment we work in.

Business process management practices and techniques are widely used.  In many cases, they have produces very valuable results.  However, the field is still quite young.  As in any young field, there are failures as well as successes.  I’ve seen projects succeed, and been quite proud of them.  I’ve also seen projects attempt to use BPM practices, waste time and money, and produce no real result.  The team would usually deliver something, but often that delivery occurred in spite of the process efforts, and not because of them.  Like any tool, using it well produces good results, and using it poorly… doesn’t. 

Let’s start with a problem

We all have to solve business problems.  Sometimes, you need to approach a problem one way… and sometimes a different approach is called for.  Business process modeling is a powerful tool.  Business capabilities provide an additional tool.  Sometimes you need to use them. 

Let’s look at one of those times.

Joe Freeflier is a business manager in the finance group of his large company.  The company has five divisions, each with completely different business models.  The divisions operate quite independently of one another.  They don’t share the same sales force, and they don’t really speak with the same customers.  Each division has its own plants, and its own workforce.  Joe, unfortunately, works for corporate.

You see, Joe is responsible for maintaining a set of business controls, as well as insuring that each division’s revenue recognition systems and processes are compliant and auditable.  He can see how the transactions appear on the general ledger, but he also has to make sure that some basic rules are followed in order to insure that the company is behaving in a legal and responsible manner. 

Joe has a couple of teams.  One team is focused on a large merger that the company went through in January.  His team is working with this new business to merge their financial systems with one of the existing divisions.  Another team produces important reports for the senior staff, some of which feed the quarterly corporate reporting required of publically traded companies.  A third team performs spot audits and works with the divisional finance leads to insure smooth reporting all up.  Joe’s customers are really the divisions themselves… and each of those divisions have their own business processes.

Joe needs some help.  The new merger has caused some churn.  His team is having a hard time working with the new business unit, and his manager has told him not to “govern them out of business.”  Now, Joe meets every month with Jürgen, his contact from IT, and at one of those meetings, Joe vents about his current problem.  Jürgen suggests that Joe speak with his business architect Sally, and a meeting is arranged.

Sally spends some time working with Joe to understand his concerns, and now has two choices. She can suggest either a process-centric approach or a capability centric approach.  Sally does not know if the problem can be fixed with a business process change.  She doesn’t know if the tools need to change, or the policies need to change, or the information collected needs to change, or if it is a training problem.  She just knows that Joe needs help.  Let’s walk through her thinking:

Process centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She proceeds to spend time with each of Joe’s divisional customers to map out their business processes, making sure that she is fairly accurate yet high level.  Three of the divisional teams have never mapped out their processes, but one has.  She starts there, and the process looks like a standard she is familiar with.  Unfortunately after interviewing some of the staff in that division, it is clear that they don’t actually follow that particular process.  So she falls back to a standard definition from an industry group, and spends a couple of meetings getting everyone to the same very-high-level process model.   Ten weeks have gone by, but she’s made some progress in understanding the landscape. 

Now, Sally visits the newly merged team and spends some serious time understanding what their existing process is, and how it may be different.  She finds that their business is based on a kind of “consignment” financing mechanism, and the revenue recognition processes that Joe uses have to be able to handle a number of new business events that he never dealt with before.  So she returns to speak with Joe about tracking these new events, and trying to fit the new financing mechanism into his controls.  Joe puts two of his team onto a small
project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system.  As it turns out, Joe doesn’t need to change his processes… what he needs is to change the way information is collected to adapt to new processes.  Joe creates his controls, and creates a set of IT requirements for the IT team to fulfill.  Sally is done.

Sally was successful, and her effort took about four months to do.  Along the way, she learned a great deal about the financial processes, and four divisional leaders now have a process model for their work.  Remember that three didn’t feel the need to create one before, and the fourth didn’t use their model.  Six months later, none of them refer to the process model at all, and it has become “shelfware.”

Capability centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She spends a few days working intensively with Joe.  She has a capability taxonomy that she brought with her from another project.  Her first goal is to get a small list of capabilities that Joe sees as valuable.  After about three or four days, she has a list of capabilities that his team needs to perform in their duties.  These capabilities are “bits of process” that his team owns and needs to do consistently, regardless of the higher-level processes that his customers use.  They are the “standard parts” of processes that his customers have taken a dependency on him to perform well. 

Now, Sally visits the newly merged team and spends some time understanding what their overall process is.  Note: Sally is looking at their process!  She looks to see whether the new unit would benefit from Joe’s finance team and looks for ways to plug Joe in.  It becomes immediately apparent that Joe has some expectations that won’t fit their business.  The new business is based on a kind of “consignment” financing mechanism, and Joe is assuming a more traditional supplier-retailer business relationship.  So Sally comes back to Joe and asks him for details about his assumed business processes.  She works with Joe for another week, charting out a narrow slice of business processes from Joe’s point of view.  She then goes back to the new unit and maps out the same narrow space on a process model.

She presents these two process maps to Joe, who now understands the problem.  Joe puts two of his team onto a small project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system. 

Both methods got to the same result.

The capability effort got us there much faster.  Using business capabilities to identify the problem, and narrow the focus of the team, Joe was able to get his team to solve the problem within about four weeks of Sally’s arrival.  She didn’t have to meet with the divisional leaders even once, and she didn’t produce an all-up process model.  Had she stuck with the process-based approach, it would have take three times that long.  Along the way, the process approach produced an interesting model, but it was not later used by anyone. 

Note that, according to Lean manufacturing, the intentional creation of an output that is not actually used by anyone, is waste.  The use of capabilities allowed Sally to remove the wasteful act of creating a high-level process model. 

What I did not do

I did not answer the question: “what is a capability?”  It was not my goal, in this post, to answer that question.  My goal is to show my friends that a tool produced a good result.  If my friends want to use the tool, defining it is unnecessary.  If my friends don’t want to use the tool, defining it won’t matter.

Did you learn what a hammer was by having someone define it to you, or by swinging at a couple of nails? 

Was this a contrived example?

It was an example derived from experience.  That said, there are equally compelling examples where using the word “business capability” generates confusion.  If Sally had gone to the new business unit and had said “I know you look at things as end-to-end processes, but I want to introduce you to the concept of business capabilities,” then she would have failed in her job as a business architect.  Sally could no more use capabilities with the new business unit than she could have taught a teenager to drive by teaching him how to overhaul the transmission. 

Capabilities are a complexity.  Some business stakeholders live at that level of complexity already, and they WANT to work at that level.  For them, capabilities make sense.  Other business stakeholders live at the highest levels of end-to-end experiences.  For them, capabilities make no sense at all.

The New Life of Joe – Part Three – The Users Are Coming!

By |2007-10-08T13:47:00+00:00October 8th, 2007|Enterprise Architecture|

Joe was in a good mood when he walked into the meeting with his Process Management leads for the first time.  Perhaps is was because Selina had just walked him through a consistent process for tracking and managing project information that didn’t keep everyone in “fire fighting mode” all month long.  “Orderly is good,” he used to say, and he believed it.  Ever since coming to this IT group, Joe has had a series of “rude awakenings” about their totally different way of delivering software.  This day was a good day.

That mood was about to change.

(Authors note: this is the third and final installment in a series of articles on Joe Freeflier, a new IT manager taking over a SOA+BPM driven IT group.  See Part 1 and Part 2 ).

When Joe sat down, he met his three process leads.  There was one for each business area that he worked with: Sales, Marketing, and Public Relations.  They were very different business areas, yet they maintained a very nicely integrated portal that all of their professionals, internal and external, used to do their work. 

After a round of introductions, Joe asked if they had project status available in the same portal that the shared services team used.  When they answered in the affirmative, Joe opened up the portal to look at the Marketing team’s project list, and stopped dead in his tracks.

There was one project.  The end date was the end of the fiscal year.  The budget was large enough to pay for the salary of every person in the team. 

Joe turned to Tom Rankle, head of the Marketing process team and asked for a rundown of project status and deliverables.

“Well, Joe, we don’t manage our team by project status and deliverables.  We manage by customer value points.  We have delivered 61 value points to the Marketing team this month through the updates to the advertising platform workflow and the new reporting interface for Marketing management.  That puts us right on target for delivery for the quarter.” 

“Customer Sat is running at 80% and our delivery backlog is sitting at an optimum level of six weeks of likely work.  Team morale is high, and our overtime ratio has been kept under 5% for the fifth month in a row.  Our current risks are that the new lead entry service update won’t ship in November, which would slip our updates to the event interface by two months.  Shared services has posted the risk as “yellow” so we are releasing the event update without the new service.  We will revisit it in the spring, after the big winter conferences.

I’d say we are pretty healthy.”  Tom finished by handing a small set of papers to Joe with all of these points in nice graphical format, showing steady values or steady trends. 

Joe was immediately lost. 

Where was the list of projects?  Where were the budgets and deliverable dates and change control processes?  The bug report triages, and the eternal fights over project scope? 

“Back up, Tom.”  Joe had to admit to his leaders that he wasn’t following the thread.  “I’m not sure I’m with you.  Can you walk me through the way your teams work?”

Marcie jumped in.  She was Tom’s peer, running the Sales process team.

“Let me give you some history…

“About two years ago, we were in a bind.  Our projects were always late.  Our customers were complaining all the time.  Every project was questioned, challenged, picked apart.  We would say something would cost 1 million, and the customer would say “you have half that.”  Most of the code was brittle, and team morale had gone below “low” to a kind of political viciousness… the most senior folks got to write new code, while the new guys always had to maintain the junk. 

“Then Michaela brought in the SOA and BPM guys.  We split IT up into shared services and process teams.  Our teams write the process bits.  We do workflows in the workflow management system, and we write the user interfaces.  The shared services team (or SST) provides data through services.  We own NONE of the data ourselves. 

“As a result, the stuff that changed most frequently, process and user interface, moved to our teams, while the stuff that needed to be stable (data and information management) remained with SST.  By breaking things up this way, the process teams could specialize on one thing: quick continuous improvement.

“We looked at our value chain.  You know that all of the process folks moved over here, and we had come from a lot of different traditions: Kaizen, Lean Manufacturing, Six Sigma… We all wanted to use our own process tools to solve our own problems.

“We found that the value of careful change control processes drops dramatically when the team writing the code cannot screw up the database.  We call services, and the services protect the database.  Well kinda.  It isn’t perfect, but it works fairly well.

“So we moved to an “agile development” model.  We take small teams, give them a list of features, and ask them to deliver value at the end of the month.  Each feature has “value points” assigned by the business.  We are measured on the maximum number of value points we deliver each month.” 

Marcie stopped and took a drink from her water bottle.  Then she jumped right back in.

“What we stopped doing: big analysis and planning projects.  In fact, all notions of ‘big planning’ are absent.  We let the Strategy and Planning worry about that stuff.  We just focus on delivering small, well-tuned, changes to the processes.  We measure key indicators before and after each process change. We make the changes using process management tools, not reams of complex code.  The most complex things we write are U/I code.

“These days, the users have started writing their own code using our mashup interface in Sharepoint.  It’s reduced some of the strain for small fixes and helps the customers feel “bought in” to the whole idea of using processes and services to define IT.

“So when Tom talked about his status, he was giving you the measurables that we manage by.  We care about value points, so we are always working to increase the number of value points we can deliver each month.  If we do our job well, customer satisfaction goes up.  So far, we’ve found that we can push the delivery of value points higher, but the quality drops and so does satisfaction.  So we don’t measure by value points alone.  We aim for a target “customer satisfaction rating” of 80% every month.  Tom has been nailing it consistently.

“One other thing we found is that the amount of overtime that the teams are working is a major driver of dissatisfaction.  Team members leave when you make them consistently work overtime.  So we capture the number of “forced overtime” hours per month, weight it towards the developers, and try to keep it low.  We find that does a good job of keeping morale high.  Staff turnover has dropped off dramatically since we started this plan.

“And when a service has to be changed, we involve the Shared Services team.  We collect the information and process needs, and the Shared Services team designs the service changes.  Sometimes it is simple, but often these changes are difficult, and they occasionally slip.  We find ways to deliver value anyway, which keeps our customers happy, even if we can’t deliver things in a predictable order. 

“The backlog is a measure of the amount of work that the business wants to have done.  We try to keep about six weeks in the queue at any time.  That way, if a shared service slips off the current cycle, we have useful and valuable work for our teams to do while they wait.  It is all described in terms of features, dozens of small changes that can be done fairly independently.”  Another drink of water, and she stopped talking. 

Joe took a minute to let it sink in.  What he was witnessing was a totally new way to “do Information Technology.”  These teams were not built the same way that his prior IT teams had been, and they were not fighting the same fights.  But they had solved the biggest problems that he had been facing: how to deliver value to the business customers on a regular basis.

The answer is here: combining Business Process Management with Agile Development in business-facing process teams. 

Finally Joe was getting it.  SOA is not about services.  It is about empowering a new way to deliver value. 

As the meeting proceeded, and Joe listened intently to the numbers that each team was delivering on, his mind kept wandering to his past IT teams.  “I wonder why we didn’t do this earlier?” 

He resolved to place two phone calls.  One to his replacement in his prior group, to invite him over to see this.  The other to Michaela… to thank her.

(authors note: this is the last of a three part series on Tom Freeflier.  See Part one and Part two).

The new life of Joe – Part Two – Managing Complexity

By |2007-10-01T12:27:00+00:00October 1st, 2007|Enterprise Architecture|

Selina Colander is up in Joe’s face.  Joe Freeflier, the new IT manager for the Sales, Marketing, and Public Relations IT group, called an all-day meeting for the project managers to attend a complete budget and timeline review for all in-flight projects.  Selina is not sure it is a good use of people’s time.

 “Don’t get me wrong, Joe.  You have every right to see what is going on.”  Selina was clearly frustrated, but went on explaining.  “I’d really appreciate it if you would talk to me before calling a meeting like this.”  

Selina continued, “I would have pointed out that the team already has a standing monthly meetings to discuss progress and more importantly, demonstrate features.  We call it our “retrospective.”  As for status, we have a portal with current information that is continuously updated directly from the projects.  The retrospective meeting lasts all day for you, but the project managers and developers only spend an hour in the room, and they don’t have to prepare.  They are primarily demonstrating progress, not talking about it.  If you want data, that is in the portal.”

(Author’s note: this is the second part of a series of blog posts about Joe Freeflier.  The first post can be found here.  The third and final post can be found here.)

Joe was pleasantly surprised, as he has been many times in the past few days.  Selina spent the next hour walking him through the portal and the underlying organizational structure.

“We have six teams.  They are:

  • Strategy and planning,
  • Sales Process Development
  • Marketing Process Development
  • Public Relations Process Development
  • Shared Services
  • Business Intelligence

“Everyone runs on a cadence with releases every two months.  The dates don’t move.  Each of the Process Development teams are able to deliver more frequently, but not less frequently.  The Shared Services team may deliver upgrades to many services, but they will all occur on the same day: the tenth of the month of January, March, May, July, September, and November. 

“Funding comes in through the Strategy and Planning team that allocates projects to each of the Process teams.  These teams own the user experience and all long-running business processes and workflow.  However, they do NOT own a single database among them.  Not one.  All operational data is managed, and all services delivered, by the shared services team.  The Business Intelligence team is responsible for managing the reporting infrastructure.

“This allows us to avoid a huge amount of overhead,” Selina pointed out.  “We did a study to show the amount of time that we spend in managing our projects.  We figured that good project management could reduce project risk by about 15%, but we were spending about 30% of our net time on project management, oversight, and control.  The distraction was huge.  Everyone was worried about managing the projects, to the point that we were forgetting to demonstrate progress on a regular basis.  Michaela changed all that.”

At the mention of her former manager’s name, Selina brightened.  She clearly had immense respect for Michaela, and Joe got the impression that if she could, she would have followed her when she left and moved out west.  He was really glad she had stayed. 

Joe thanked Selina and then spent the next hour alone, thinking about how he was going to take over this team.  They had created a system, not just a set of processes.  They had not been busy fixing little things about software development, like his last team.  They had started over, starting with the basic principles. They had rewritten the rules, and now he had to learn them, and quick, before he screwed up this machine by tinkering where it wasn’t broken.

What surprised Joe the most wasn’t that Michaela had created a good system, but that it moved so quickly.  It was all he could do to keep up.  Perhaps he didn’t need to. 

If he could go back in time and take a newspaper press operator from the 17th century, where a newspaper was printed one sheet at a time, and put them into a modern newspaper facility with the paper whizzing by so fast that you couldn’t see it, they would be starting over from scratch.  He wondered if he wasn’t starting over as well.

Better to learn the ropes first.  He headed off to his next meeting, this time with the lead architect for the IT group.  He was to learn about the Business Process Management technology that the process teams used. 

Something told him that this was not going to be boring…

(Author’s note: this is the second part of a series of blog posts about Joe Freeflier.  The first post can be found here.  The third and final post can be found here.)

The New Life of Joe – Part One – Off to a cold start

By |2007-09-27T12:23:00+00:00September 27th, 2007|Enterprise Architecture|

Joe Freeflier is not a lucky man.  He’s been promoted.

Oh, he wanted the promotion.  He asked for the promotion, but it is a lateral move, and he had no idea of the difference between his old job and this new, unfamiliar role.  When he came to work for the first day in the new building, in a new city, he was thrust into a series of meetings that he wasn’t expecting, where people were looking to him for ideas, not decisions.  His team filled in, but he felt like an observer, completely out of place.

His wife was so happy when he told her about the promotion.  Joe is a middle-aged guy, a hard worker.  He’d been at the company for about seven years, all of it in the IT team.  He started as a program manager, coming over from the downtown bank where he had been an IT project manager.  He’s a thin man, having lost 30 pounds a few years back.  He’s taller than average, making him look even thinner, and he comes to work in distinctly comfortable clothes. He has always kept a modest and steady approach to getting things done.  He will push for changes, where needed, but mostly his attitude is “if it ain’t broke, don’t fix it.”  If you want someone to keep the trains running on time, Joe is your man.   

Joe just took over the management of a good-sized IT group in his company.  His group is responsible for all the systems used by the Sales, Marketing, and Public Relations functions within this global multinational company.  Four years ago, each of the operating companies in the multinational had their own Sales and Marketing teams, but they were all brought together under a single executive and he worked to get uniform processes and consistent reporting.  To all accounts, from the business side, the merger was successful.

The IT path was not so easy.  Joe’s predecessor, Micheala Fling, had inherited four sets of Sales tools, four sets of Marketing and communications tools, and tools originally set up for the PR team.  The tools overlapped, created information in different structures.  Business Intelligence was a joke.  When the business teams combined, so did the IT teams, and among the 600 or so developers, testers, support and operations folks, there was no consistent “anything.”   

Micheala turned to a group of SOA architects in the company to fix the problem.  They proposed changes and she made them.  She was assertive and constant, pushing for change without pushing people out or stepping on too many toes.  She had a good relationship with the head of the new combined Sales and Marketing group and she worked to keep it that way.  She completely changed the way her IT group worked.  She used to say “When a toy is broken, you toss it.  When a car is broken, you fix it.  We are discarding the toys and fixing the cars.”  When she left, her staff gave her a toy car.  It was a good moment.

And now Joe has inherited the “fixed” IT that Micheala left behind.  Joe had spent the last four years in the supply chain IT team in Michigan.  Now he was in Ohio, at corporate headquarters, inheriting something that didn’t run the way he was used to, didn’t look like the group he had.  Micheala left to become the CIO of a midsized Restaurant company somewhere out west.  She took three of her top folks with her. 

Micheala changed a lot of things.  She hoped that the changes would last.  This was the test… “The rubber was going to meet the road.”  Could her changes be sustained?  Would the racecar that she had built out of tractor parts hold together with a new driver?  Joe was about to find out.

Fortunately, Joe has Selina Colander.  She was Micheala’s right hand, and helped set up all the processes and policies for the IT team.  When others left to go with Micheala, Selina stayed, and now she was the only thing keeping Joe sane.  Selina is not a tall woman or a thin woman.  An African American with a warm personality, and a taste for brightly colored clothes, she’s the kind of joyful person that people just gravitate to. 

Except right now… right now, she’s in Joe’s face.

(Author’s note: This story takes three blog posts to tell.  The other two entries are linked below)

Part two – Managing Complexity

Part three – The Users are Coming