A new feature of BPM-suites is the possibility to simulate.
While playing around with IBM's tool and Savvion, i started wondering about the real requirements for simulation.
Having a background in Simula simulations (a, somewhat legacy, programming language for simulations, which, by the way tought me OO thinking in a really good way!), I am disappointed about the features of the current simulation engines....
Some stuff that I miss, and was not able to get going:
Working days and working hours
For realistisch throughput and cycle time, especially in financial organizations, it is essential to be able to model workingtime (9:00 - 17:00) and working days (no weekend, no vacation days).
Timed batches
The possibility to define a batch. A process instance comes to a certain point, and then needs to wait for the nightbatch to continue. The batch can be modelled as a resource, that will execute one of more tasks from the process instance (but then I need to be able to allocate a resource availability!). After these steps, again, the process should wait until the next working day, to continue...
Process instance allocation of a shared resource
In certain processes, there are resources that have their own schedule and maximum size.
As an example - let's assume we have a process that produces plates. Plates need to be painted (activity by a resource), and then placed in a drying room. A drying room has a certain capacity, and will take up to X plates (aka process instances, each for a certain plate). Again, I need to feature to model this resource, that is able to pickup a set of process instances, execute an activity (dry) in each of them, and then release them....
Grouping of process instances based on certain shared elements
Factories usually have production schedules, where certain tasks are combined (first we do all the products XYZ, then ABC), to minimize machine setup and improve efficiency/focus. Again, where is the possibility to do this.
Machine maintenance and setup
In more factory setting processes, we will have machines (resources), that will need setup time (when processing a certain process instance that is for a new type of product). And these machines need maintenance, leading to downtime. So, when triggered for use, a resource as a machine, should be able to take out time from the waiting process instances, due to setup time and maintenance time.
More advanced resource selection and allocation
All types of features to be able to select resources (people, machines) based on business rules, driven by (random) data in a process instance (type of product, level of investment, etc)....
Ok, my wishlist for santa for BPM simulation 2007 :-)
Friday, December 22, 2006
Monday, December 18, 2006
Classifications of BPM Suite support
What I would like to see in the next generation of BPM systems....
The flexibility to choose between taylorism and anarchism :-)
Currently, a process instance will always follow a predefined process template, based on data and business rules (if... then....): the flow paradigma.
Think: high volume, high standard processes. Mortgage processing.
But we can think of different other setups where expliciet procesmodels will not do, but where process orientation is still the good way to go. Some thoughts on possibilities:
A new view would be: the userdriven (knowledge) paradigma. In this approach, a process instance will follow a process template that can be (freely or selectively) manipulated by a user. I can see the selection of certain process sub-templates (oh, let's add these steps, and these, with these business rules) from a library (context aware) or total free tasks.
Useful for situations where we can model processes and subprocesses, but the actual decision what templates need to apply for a certain instance it too complex to model in advance.
Think: high volume, but lower standard processes. A lawsuit. Audit trail for free.
Another would be, to be able to define a template for a process in a collaborative way. An issue is born. Steps need to be taken, but not sure who what when. Not only can people define process elements, they can assign tasks to people and track progress + discussions. People can add tasks, explode tasks in subtasks, add business rules for paths in the process. A highly collaborative process environment. For instance, a sales pitch. Or a creative process, where people do want to track afterwards what happened, when, by whom.
Another would be a datadriven/event driven architecture. The ability to define a dataset (documents, data) and link incoming data to actions, that all need to take place in the context of a certain process instance. It is a concept close to the userdriven one, but now with automated startup of all types of subprocess templates, based on incoming data. A smart CRM system, that responds to customer communications (online, fax, mail, etc), and is able to relate these types of communications to each other, and take action on it.
The flexibility to choose between taylorism and anarchism :-)
Currently, a process instance will always follow a predefined process template, based on data and business rules (if... then....): the flow paradigma.
Think: high volume, high standard processes. Mortgage processing.
But we can think of different other setups where expliciet procesmodels will not do, but where process orientation is still the good way to go. Some thoughts on possibilities:
A new view would be: the userdriven (knowledge) paradigma. In this approach, a process instance will follow a process template that can be (freely or selectively) manipulated by a user. I can see the selection of certain process sub-templates (oh, let's add these steps, and these, with these business rules) from a library (context aware) or total free tasks.
Useful for situations where we can model processes and subprocesses, but the actual decision what templates need to apply for a certain instance it too complex to model in advance.
Think: high volume, but lower standard processes. A lawsuit. Audit trail for free.
Another would be, to be able to define a template for a process in a collaborative way. An issue is born. Steps need to be taken, but not sure who what when. Not only can people define process elements, they can assign tasks to people and track progress + discussions. People can add tasks, explode tasks in subtasks, add business rules for paths in the process. A highly collaborative process environment. For instance, a sales pitch. Or a creative process, where people do want to track afterwards what happened, when, by whom.
Another would be a datadriven/event driven architecture. The ability to define a dataset (documents, data) and link incoming data to actions, that all need to take place in the context of a certain process instance. It is a concept close to the userdriven one, but now with automated startup of all types of subprocess templates, based on incoming data. A smart CRM system, that responds to customer communications (online, fax, mail, etc), and is able to relate these types of communications to each other, and take action on it.
BPM and SOA - how do these concepts relate?
A number of BPM sites are writing about the connection between SOA - Service Oriented Architecture and BPM - Business Process Management.
It pushed me to think about these concepts and how they relate and differ.
Thinking about it, first we need to define what we mean by SOA. SOA seems to come in a number of flavours:
1. SOA: An architectural style.
From this perspective, SOA is a means to describe the complex reality of a system (this can be on a business, application or IT level) as a interrelated network of services.
In my view it is simply a means to reduce complexity, by breaking up the complex world of IT and business in smaller, well, let's be honest, components. These components, such as a business component, is something (people, knowledge, effort, IT, functionality, process, data) that can provide services to other components, and that will often use other components to be able to deliver it's services. With smart composition design rules (coupling, information hiding, etc) elegant architecture patterns can be composed.
Is this architectural style useful for BPM? Well, YES!
When thinking BPM (from a process architecture perspective), when defining processes and units (people, systems) that can execute (parts of) these processes, a good way to model reality helps a lot. And SOA can be a way to describe components that are able to execute parts of a process.
Depending on architecture level, we can see:
- Business components, that are used to execute a process (in reality: a concrete or abstract notion of a department of other organization unit)
- IT components, that are used to either execute parts of processes (straigh through processing), or are supporting a business component (aka people) to perform work in the process.
2. SOA: A technology
For some, SOA is also associated with technology. In this case, we talk about some type of access to functionality and data in systems, preferably on some type of open standards (think service bus/hub, SOA grid)
And for some BPM is a technology that executes processes.
While this is not my direct notion of SOA and BPM, also on this level we can see a relation.
When creating a BPM system, that executes some type of straight through processing (or mixed mode with workflow management), well, you will need services to call, as automated steps in the proces execution layer. You can develop this steps and supporting components in an adhoc fashion, but in the end it will be better to have a uniform integration strategy. SOA with open standards, that is.
Some points of view:
- When you start with a BPM tool, and want to create services to be able to perform straight through processing, you are forced to do SOA.... And soon after that, you will need SOA governance (how to decide which services are needed).
Vice versa - if you want to build a SOA based IT landscape, for a while you can work on a architecture that does not explicitely talk about proces. You might get away with a portal that uses services. Or systems that talk ot eachother p2p or eda or messagebased or subscription based, through "services".
But as soon as you want to start using SOA infrastructures in a more business oriented way, the first word that will fall is business process.... and you're back at BPM: a way to think about what services you need....
It pushed me to think about these concepts and how they relate and differ.
Thinking about it, first we need to define what we mean by SOA. SOA seems to come in a number of flavours:
1. SOA: An architectural style.
From this perspective, SOA is a means to describe the complex reality of a system (this can be on a business, application or IT level) as a interrelated network of services.
In my view it is simply a means to reduce complexity, by breaking up the complex world of IT and business in smaller, well, let's be honest, components. These components, such as a business component, is something (people, knowledge, effort, IT, functionality, process, data) that can provide services to other components, and that will often use other components to be able to deliver it's services. With smart composition design rules (coupling, information hiding, etc) elegant architecture patterns can be composed.
Is this architectural style useful for BPM? Well, YES!
When thinking BPM (from a process architecture perspective), when defining processes and units (people, systems) that can execute (parts of) these processes, a good way to model reality helps a lot. And SOA can be a way to describe components that are able to execute parts of a process.
Depending on architecture level, we can see:
- Business components, that are used to execute a process (in reality: a concrete or abstract notion of a department of other organization unit)
- IT components, that are used to either execute parts of processes (straigh through processing), or are supporting a business component (aka people) to perform work in the process.
2. SOA: A technology
For some, SOA is also associated with technology. In this case, we talk about some type of access to functionality and data in systems, preferably on some type of open standards (think service bus/hub, SOA grid)
And for some BPM is a technology that executes processes.
While this is not my direct notion of SOA and BPM, also on this level we can see a relation.
When creating a BPM system, that executes some type of straight through processing (or mixed mode with workflow management), well, you will need services to call, as automated steps in the proces execution layer. You can develop this steps and supporting components in an adhoc fashion, but in the end it will be better to have a uniform integration strategy. SOA with open standards, that is.
Some points of view:
- When you start with a BPM tool, and want to create services to be able to perform straight through processing, you are forced to do SOA.... And soon after that, you will need SOA governance (how to decide which services are needed).
Vice versa - if you want to build a SOA based IT landscape, for a while you can work on a architecture that does not explicitely talk about proces. You might get away with a portal that uses services. Or systems that talk ot eachother p2p or eda or messagebased or subscription based, through "services".
But as soon as you want to start using SOA infrastructures in a more business oriented way, the first word that will fall is business process.... and you're back at BPM: a way to think about what services you need....
Saturday, December 09, 2006
On production workflow and usefulness
There seems to be a lot of discussion on the use of BPM systems and their focus on "production workflow". See...
http://www.bpminstitute.org/articles/article/article/bpms-watch-bpm-embraces-collaboration.html
And of course, mr Brononski and Pyke "workflow sucks"
Important.
Unfortunately, there is a large group of people still thinking that everything in an organisation can be pushed into fixed algoritmes. BPEL as the process programming language. It leads to "workflow sucks", which is not the right direction for BPM...
My theory: probably 20% of business work can be defined as production workflow processes. These are usually the so called Hygiene factor processes (e.g. those things you simply have to do right, otherwise you are a really dumbo). Opportunity for BPM? Unfortunatly yes, simply think of all those companies that are still not able to handle correct invoices, orders, complaints, call's, etc. So, BPM analysts, do your thing.
But then there are many processes that have other properties.
What properties do processes have actually? Or work in general?
A simple brainstorm:
- Volume and frequency (how often and in which volume is the work done)
- Predictability/structure (does the work follow a certain flow, following certain patterns and rules?)
- Amount of collaboration (how many people are involved while performing tasks)
- Risk (is correct execution of the task/process of vital importance to the company)
More - input welcome!
Based on this set of dimensions, we can start to classify work and processes: a process taxonomy.
Some will be: high volume, very structured, low collaboration. And we can chose to support these with BPMS, with production workflow: each process instance has the same process template. Great for lean-six sigma.
Some will be: high volume, less structured, low/more collaboration. This is something for case management - BPMS-tools that support process instances, where the instance can use one of more process templates (maybe even unique for this case)
And some will be high collaboration, less/no structure. BPM structured process support? No!
Automation/IT support possible? Well, yes, but with carefull thinking. High Performance Workplace, knowledge management, groupware, process/context aware technology, HIM.
It reminds me of this great article of a Xerox guru:
http://www.fastcompany.com/online/01/people.html
The lesson: for these types of "processes", don't send a BPM production workflow analyst... Users + the analyst will get very unhappy. Send in a anthropologist!
And don't forget, if 20% is hygiene production workflow (let's call them simpy best practices), the other 80 are not. Make sure they stay your "next practices" - competitive edge.
http://www.bpminstitute.org/articles/article/article/bpms-watch-bpm-embraces-collaboration.html
And of course, mr Brononski and Pyke "workflow sucks"
Important.
Unfortunately, there is a large group of people still thinking that everything in an organisation can be pushed into fixed algoritmes. BPEL as the process programming language. It leads to "workflow sucks", which is not the right direction for BPM...
My theory: probably 20% of business work can be defined as production workflow processes. These are usually the so called Hygiene factor processes (e.g. those things you simply have to do right, otherwise you are a really dumbo). Opportunity for BPM? Unfortunatly yes, simply think of all those companies that are still not able to handle correct invoices, orders, complaints, call's, etc. So, BPM analysts, do your thing.
But then there are many processes that have other properties.
What properties do processes have actually? Or work in general?
A simple brainstorm:
- Volume and frequency (how often and in which volume is the work done)
- Predictability/structure (does the work follow a certain flow, following certain patterns and rules?)
- Amount of collaboration (how many people are involved while performing tasks)
- Risk (is correct execution of the task/process of vital importance to the company)
More - input welcome!
Based on this set of dimensions, we can start to classify work and processes: a process taxonomy.
Some will be: high volume, very structured, low collaboration. And we can chose to support these with BPMS, with production workflow: each process instance has the same process template. Great for lean-six sigma.
Some will be: high volume, less structured, low/more collaboration. This is something for case management - BPMS-tools that support process instances, where the instance can use one of more process templates (maybe even unique for this case)
And some will be high collaboration, less/no structure. BPM structured process support? No!
Automation/IT support possible? Well, yes, but with carefull thinking. High Performance Workplace, knowledge management, groupware, process/context aware technology, HIM.
It reminds me of this great article of a Xerox guru:
http://www.fastcompany.com/online/01/people.html
The lesson: for these types of "processes", don't send a BPM production workflow analyst... Users + the analyst will get very unhappy. Send in a anthropologist!
And don't forget, if 20% is hygiene production workflow (let's call them simpy best practices), the other 80 are not. Make sure they stay your "next practices" - competitive edge.
Process automation? Two words
When using BPM Suites, two concepts are important:
1) Straight Through Processing.
What is it? Well, basically it is "hands off". Let a trigger start a process, supplying sufficient data, let a process execution engine walk through all process steps, and execute services towards systems (rules, data, output). Let the BPMS collect data, so that monitoring can be done (real time). And possibly, based on business rules, let certain STP processes be presented at some stage to a human being, as a check (every random 10 out of 100 orders, we visually check, to make sure we are doing the right things)
2. Skill based distribution.
The new concept of workflow management: the right task, at the right time, for the right employee. Basically, based on process characteristics (type of process, product), employee properties (experience in certain process or products, or even at task level, workload, availability) and process instance/input data (product, complexity, priority, certain tresholds in terms of money), pick a set of employees to assign this task to.
Together - pure automated processing power.
How to design and tune it? Through business rules.
1) Straight Through Processing.
What is it? Well, basically it is "hands off". Let a trigger start a process, supplying sufficient data, let a process execution engine walk through all process steps, and execute services towards systems (rules, data, output). Let the BPMS collect data, so that monitoring can be done (real time). And possibly, based on business rules, let certain STP processes be presented at some stage to a human being, as a check (every random 10 out of 100 orders, we visually check, to make sure we are doing the right things)
2. Skill based distribution.
The new concept of workflow management: the right task, at the right time, for the right employee. Basically, based on process characteristics (type of process, product), employee properties (experience in certain process or products, or even at task level, workload, availability) and process instance/input data (product, complexity, priority, certain tresholds in terms of money), pick a set of employees to assign this task to.
Together - pure automated processing power.
How to design and tune it? Through business rules.
6 thoughts about BPM
Well, let's confuse you. Let's position BPM.
1) Organizations do not exists. What does exist are legal units (paper), and groups of people performing work, to achieve their own objectives, and/or working together to achieve a (part of) group objectives
2) Processes do not exist. What does exist is people that perform activities. And sometimes these people perform activities in such a way that a patterns seems to appear. Through interventions these patterns can be more enforced, so that the chance that the pattern reappears, grows. Interventions can use a process (model) as one of the ways to reach this.
3) Procesmodels are not the process. A model is always less than reality (unless it’s a beauty contest model…). So a procesmodel will miss certain aspects of reality. Procesmodels, as used in interventions have therefore limited value, and can also be inappropriate.
4) In many organizations much of the work done, is not recognized as a (shared notion of a) “process”
5) Process-knowledge is often not explicit. It is stored in people’s head, and sometimes in IT systems. The same is true for business rules.
6) Every process effort (modeling it, discussing it, measuring it, trying to influence people to alter their "patterns", introducing/changing technoly) can be called "Business Process Management"
7. BPM is a set of tools for human intervention. To try to make people follow certain patterns, which comply better with the (perceived) organization's or manager's goals and ambitions.
Not more, not less.
1) Organizations do not exists. What does exist are legal units (paper), and groups of people performing work, to achieve their own objectives, and/or working together to achieve a (part of) group objectives
2) Processes do not exist. What does exist is people that perform activities. And sometimes these people perform activities in such a way that a patterns seems to appear. Through interventions these patterns can be more enforced, so that the chance that the pattern reappears, grows. Interventions can use a process (model) as one of the ways to reach this.
3) Procesmodels are not the process. A model is always less than reality (unless it’s a beauty contest model…). So a procesmodel will miss certain aspects of reality. Procesmodels, as used in interventions have therefore limited value, and can also be inappropriate.
4) In many organizations much of the work done, is not recognized as a (shared notion of a) “process”
5) Process-knowledge is often not explicit. It is stored in people’s head, and sometimes in IT systems. The same is true for business rules.
6) Every process effort (modeling it, discussing it, measuring it, trying to influence people to alter their "patterns", introducing/changing technoly) can be called "Business Process Management"
7. BPM is a set of tools for human intervention. To try to make people follow certain patterns, which comply better with the (perceived) organization's or manager's goals and ambitions.
Not more, not less.
BPM - They are all doing it...
While wandering around organizations, it strikes me time after time...
There are process analysts, that are modeling business processes, because the accountant pushed the business manager that it was needed (think - compliance)
There are expensive consultants that are modeling processes, because a CEO wants to assess sourcing options
There are business people, that are modeling business processes, because the workforce needs support - knowledge what to do when.
There are architects that are designing process architectures. Because, uhm, they like pictures and want to reduce complexity, understand the here & now and plan for the future
There are business analysts, that model processes, to understand and define requirements for various applications
And... there are developers, working on a SOA (or legacy app), which has process aware elements, and they are modeling and coding a process (in code, or in a service orchestration BPMS).
See the overlap? We basically have 6 groups (sometimes more, sometimes less), doing proces modelling. All from different angles, all storing results in different tools.
Let's call these process silo's.
What a waste...
There are process analysts, that are modeling business processes, because the accountant pushed the business manager that it was needed (think - compliance)
There are expensive consultants that are modeling processes, because a CEO wants to assess sourcing options
There are business people, that are modeling business processes, because the workforce needs support - knowledge what to do when.
There are architects that are designing process architectures. Because, uhm, they like pictures and want to reduce complexity, understand the here & now and plan for the future
There are business analysts, that model processes, to understand and define requirements for various applications
And... there are developers, working on a SOA (or legacy app), which has process aware elements, and they are modeling and coding a process (in code, or in a service orchestration BPMS).
See the overlap? We basically have 6 groups (sometimes more, sometimes less), doing proces modelling. All from different angles, all storing results in different tools.
Let's call these process silo's.
What a waste...
Customer journey, BPM and cross-channel service
Hm, one of those nice moments occured, while talking first to a chief architect of a major bank, and later to one of my close friends, who is a evangalist on new media (modern marketing with modern methods). 1 + 1 = 3, you know the feeling.
The chief architect was explaining me how they were developing a method to create technology to support processes (front office/customer servicing) that cross channels. Meaning: I am a bank-client, I start with channel A (say, the Web), take 2 steps, and then call a call-centre. They do NOT start a new process, but are able to pickup the process where I left it, and take it further, to fullfillment, of possibly handing it back to me (on another channel, say web, paper, phone, visit, whatever). So, I would call this the cross-channel CRM process.
Now my marketing evangelist, who linked this to a new concept. He called it the "customer journey". Hm, a concept that rings. Remember your own life - "He, I want.... I am interested in... where/how/when can I....". The search along companies, through web, phone, adds, to find that company that you trust enough to fill that need.... It's called the customer journey. Your journey.
But that brings together 4 concepts:
1 - your service offerings (what needs do you want to fill?)
2 - the customer interest taxanomy and channel choices
3 - the custumer journey
4 - your, CRM cross channel process (BPM)
So, do you (as a front office marketing/CRM/BPM analyst) see these concepts in your organisation? Acting on it?
The chief architect was explaining me how they were developing a method to create technology to support processes (front office/customer servicing) that cross channels. Meaning: I am a bank-client, I start with channel A (say, the Web), take 2 steps, and then call a call-centre. They do NOT start a new process, but are able to pickup the process where I left it, and take it further, to fullfillment, of possibly handing it back to me (on another channel, say web, paper, phone, visit, whatever). So, I would call this the cross-channel CRM process.
Now my marketing evangelist, who linked this to a new concept. He called it the "customer journey". Hm, a concept that rings. Remember your own life - "He, I want.... I am interested in... where/how/when can I....". The search along companies, through web, phone, adds, to find that company that you trust enough to fill that need.... It's called the customer journey. Your journey.
But that brings together 4 concepts:
1 - your service offerings (what needs do you want to fill?)
2 - the customer interest taxanomy and channel choices
3 - the custumer journey
4 - your, CRM cross channel process (BPM)
So, do you (as a front office marketing/CRM/BPM analyst) see these concepts in your organisation? Acting on it?
BPM is a management discipline...
Ah, it's late, so you'll have to forgive me for being blunt.
I was reading a good article on BPM from Gartner, and felt better about BPM.
Why? Well, the hype of BPM is reminding me a lot of the CRM hype late 90's.
Remember? CRM suddenly was linked to technology - CRM = Siebel.
No no no. When I ask managers "what's financial management", nobody answers, "well, that's general ledger/accounting system XYZ". Thank you.
Financial management, if you ask managers and experts, is a management discipline. Through different tools, such as budgeting, accounting, reporting, planning, etc, a company tries to manage one of it's assets: money.
Well, CRM is another management discipline. It tries to manage another important asset: customers. It, again, uses different tools, such as target audience, customer needs, customer life cycle, customer scoring, and plans/monitors how the company deals with customer needs. How it communicates, what is gathers/stores and remembers about a customer, how it makes sure it serves the customer right. And a bit of cross-selling/up selling on the side..
Did you read Siebel in there? No. Technology (Siebel is part of it) can help these tools within this management discipline. If customer volumes and the amount of customer data and customer communication is getting high, technology can help... Not more, not less.
Back to BPM - Business process management. Again - it's NOT technology. It's a management discipline, focusing on managing processes as an asset. An asset? Yes - if you take the time with your people and (if you want) technology, you can develop a focused set of activies towards the objectives of your company. More - you can start thinking of improving those activities in a structured way. We are talking again about tools and concepts, such as process life cycle, process model, process data, process improvement frameworks.
Processes - a competitive edge. Look at the Toyota's, Dell's, Nike's, McDonalds of today. They really though about their processes (including flow, agility, cashflow, business model, sourcing, etc). And are improving it every day, staying ahead - their processes are assets!
And Technology? Well, sure, one can think of using tools, when volumes get higher, and efficiency needs speed. BPM-suites can help (when mature enough).
So, let's create a common statement: BPM? It's a management discipline. And technology is usefull, and can be used to help out BPM efforts.... So, let's get to work!
I was reading a good article on BPM from Gartner, and felt better about BPM.
Why? Well, the hype of BPM is reminding me a lot of the CRM hype late 90's.
Remember? CRM suddenly was linked to technology - CRM = Siebel.
No no no. When I ask managers "what's financial management", nobody answers, "well, that's general ledger/accounting system XYZ". Thank you.
Financial management, if you ask managers and experts, is a management discipline. Through different tools, such as budgeting, accounting, reporting, planning, etc, a company tries to manage one of it's assets: money.
Well, CRM is another management discipline. It tries to manage another important asset: customers. It, again, uses different tools, such as target audience, customer needs, customer life cycle, customer scoring, and plans/monitors how the company deals with customer needs. How it communicates, what is gathers/stores and remembers about a customer, how it makes sure it serves the customer right. And a bit of cross-selling/up selling on the side..
Did you read Siebel in there? No. Technology (Siebel is part of it) can help these tools within this management discipline. If customer volumes and the amount of customer data and customer communication is getting high, technology can help... Not more, not less.
Back to BPM - Business process management. Again - it's NOT technology. It's a management discipline, focusing on managing processes as an asset. An asset? Yes - if you take the time with your people and (if you want) technology, you can develop a focused set of activies towards the objectives of your company. More - you can start thinking of improving those activities in a structured way. We are talking again about tools and concepts, such as process life cycle, process model, process data, process improvement frameworks.
Processes - a competitive edge. Look at the Toyota's, Dell's, Nike's, McDonalds of today. They really though about their processes (including flow, agility, cashflow, business model, sourcing, etc). And are improving it every day, staying ahead - their processes are assets!
And Technology? Well, sure, one can think of using tools, when volumes get higher, and efficiency needs speed. BPM-suites can help (when mature enough).
So, let's create a common statement: BPM? It's a management discipline. And technology is usefull, and can be used to help out BPM efforts.... So, let's get to work!
Monday, December 04, 2006
SOA, VOIP and BPM - new technology for the phone channel
Sorry, but sometimes I can be too technology driven. A business need is important, but every now and then you see a number of technology developments, link them and start dreaming about the possibilities (while not focusing on a business issue to solve). This time a news-item triggered me: as a result of the move to voice of IP (voip) most modern telephone switches (PBX, the central unit in a company that controls all phones and lines) become open: a set of services.
We are talking about services such as:
- Recognize that someone is calling (and their caller ID)
- Forward the call to an IVR (interactive voice response system) to enable the caller to supply certain information (reason of calling, identification, department of interest)
- Place the incoming call in a queue
- Link the incoming call to a certain phone, and make it ring. Or faster: link the incoming call to a certain headset from a certain call center agent, and inform this agent of the call
- Forward the call to a another waiting queue, another agent, or IVR
- Recognize that the caller said something or pressed a dialtone
- Play a certain message to the caller (a welcome, a question “please dial X” , information “so many are waiting, waitingtime is…”, some music)
- Outbound: dial a number and recognize not answered, busy, answered by voicemail, or answered
- Information services such as number of calls in period X, service level of period (a much used metric in call center land: the % of calls that you were able to pickup and serve that were waiting less than (mostly) a minute)
Hm, so a new set of services. Ah, a set of services that you can include in applications. That gives a whole new meaning to composite applications – now including voice/telephone!
If you combine this with a BPMS (business process management system) that supports workflow and SOA, the VOIP aware applications can support agents and management with things as:
- A call agent can be supported with a simple application in which he can directly control his phone and current caller, including forwarding the call to certain business processes
- A call can be forwarded to a business process engine, following a process model that was setup by analysts. Based on business rules, the engine will know what to do with the call – forward, send to IVR, waitqueue, escalate, etc.
- An IVR is no longer an expensive package. You can do it yourself with the BPMS (a procesmodel with actions as “play message X”, “recognize dialtone”, “determine next action”) and change it easily as well
- Controlling a PBX and integrating it with business processes is becoming a normal IT development task
- Integrated PBX and business process performance information is possible – which allows for better tracking (how many calls resulted in new business?)
- Phone and PC become one. You don’t look up a number on screen, and then dial it – you click dial… (or tell the computer on your headset “dial”)
Is this new? No. So why is this SOA-VOIP interesting from a business perspective? Well, up until recently IT and PBX/Phone services in a company where first of all quite separated. This resulted in
- Separate management information streams
- A phone and a PC, not connected
In addition PBX systems were quite closed. It meant
- expensive software, expensive specialists
- specific software for specific switches, and expensive solutions.
- Different, mostly not integrated solutions for IVR, PBX management, etc.
With a simple open and services based PBX, creating, using and administrate applications that are phone and call aware, will become a much more simple task, cheaper, more standard and less supplier dependent. This means for the business that your next project for a new product, a new service or new organization unit, setting up all the electronic channels for interactions towards your customers becomes one project – for web, wap, paperinput/output and now… phone.
Hope for the future is of course a SOA standard for PBX’s. Some XML-based, OASIS driven standard, that integrates well with the other BPMS and SOA standards. Can the Nortel’s, Ericssons, etc. start talking?
We are talking about services such as:
- Recognize that someone is calling (and their caller ID)
- Forward the call to an IVR (interactive voice response system) to enable the caller to supply certain information (reason of calling, identification, department of interest)
- Place the incoming call in a queue
- Link the incoming call to a certain phone, and make it ring. Or faster: link the incoming call to a certain headset from a certain call center agent, and inform this agent of the call
- Forward the call to a another waiting queue, another agent, or IVR
- Recognize that the caller said something or pressed a dialtone
- Play a certain message to the caller (a welcome, a question “please dial X” , information “so many are waiting, waitingtime is…”, some music)
- Outbound: dial a number and recognize not answered, busy, answered by voicemail, or answered
- Information services such as number of calls in period X, service level of period (a much used metric in call center land: the % of calls that you were able to pickup and serve that were waiting less than (mostly) a minute)
Hm, so a new set of services. Ah, a set of services that you can include in applications. That gives a whole new meaning to composite applications – now including voice/telephone!
If you combine this with a BPMS (business process management system) that supports workflow and SOA, the VOIP aware applications can support agents and management with things as:
- A call agent can be supported with a simple application in which he can directly control his phone and current caller, including forwarding the call to certain business processes
- A call can be forwarded to a business process engine, following a process model that was setup by analysts. Based on business rules, the engine will know what to do with the call – forward, send to IVR, waitqueue, escalate, etc.
- An IVR is no longer an expensive package. You can do it yourself with the BPMS (a procesmodel with actions as “play message X”, “recognize dialtone”, “determine next action”) and change it easily as well
- Controlling a PBX and integrating it with business processes is becoming a normal IT development task
- Integrated PBX and business process performance information is possible – which allows for better tracking (how many calls resulted in new business?)
- Phone and PC become one. You don’t look up a number on screen, and then dial it – you click dial… (or tell the computer on your headset “dial”)
Is this new? No. So why is this SOA-VOIP interesting from a business perspective? Well, up until recently IT and PBX/Phone services in a company where first of all quite separated. This resulted in
- Separate management information streams
- A phone and a PC, not connected
In addition PBX systems were quite closed. It meant
- expensive software, expensive specialists
- specific software for specific switches, and expensive solutions.
- Different, mostly not integrated solutions for IVR, PBX management, etc.
With a simple open and services based PBX, creating, using and administrate applications that are phone and call aware, will become a much more simple task, cheaper, more standard and less supplier dependent. This means for the business that your next project for a new product, a new service or new organization unit, setting up all the electronic channels for interactions towards your customers becomes one project – for web, wap, paperinput/output and now… phone.
Hope for the future is of course a SOA standard for PBX’s. Some XML-based, OASIS driven standard, that integrates well with the other BPMS and SOA standards. Can the Nortel’s, Ericssons, etc. start talking?
Subscribe to:
Posts (Atom)