Latest Updates: bpm software RSS

  • Brian

    Ideological Fanaticism + Open Source Software = Open Core Debate

    brian 11:13 pm on July 15, 2010 | 0 Permalink | Reply
    Tags: bpm software, BPM Training, Compiere, , Open Core Debate, , , OSI

    Like many others I have been following the flurry of posts and comments that followed Jorg Janke’s blog post about Compiere. Without a doubt Jorg’s post is a great contribution to those of us involved in the day to day business of running open source software companies.

    However, most of the subsequent posts and comments focused on a hackneyed ideological debate surrounding open core and open source software in general. Is it just me or is this discussion really only interesting to an insular herd of open source VCs plagued recently by less than stellar returns and the cadre of lawyers that service this sector?

    For those of us that spend our days and nights running profitable, non-VC-run open source software companies, there is often little time for such banal ideological chatter. My shareholders are more impressed by numbers (the ones on the bottom line of the income statement), and our company is focused on creating world class software, engaging with a vibrant community to do so, and delivering value day in and day out to customers. With this in mind, who has time for an “open core” debate which completely misses the subtleties of running most successful companies?

    Since I seem to have appreciated something different in Jorg’s blog, here are a few of the points I feel are good take aways:

    1. Training. I guess this should be obvious, but for some reason it is easy to forget. I immediately cut and pasted some of Jorg’s thoughts and sent them directly to our head of sales. “… people tend to like the application they had most exposure to (and understood best).” This just drives home the point that we are already seeing. Those that take our BPM Software training course tend to continue on and purchase other services related to our BPM and Workflow Software. Jorg’s 80% up-sell number is interesting, especially for us since we are operating in such a similar space (BPM Software – Enterprise Software). Enterprise software tends to have a longer learning curve and so you have to figure out a way to get users over the “suck factor” to use the words of another open source exec/friend. I know we know this, but it never hurts to hear it again and go back to our strategy and see if we are really executing on it. Are our sales people taking the leads from trainings and performing the appropriate follow up? Are they being placed in the appropriate lead nurture campaigns? Are we focusing enough resources on training?

    2. Partners. You either love ‘em or you hate ‘em. Or in the case of Open Source Software – both! If there was ever a difficult subject in the world of open source, it is the subject of partners. Why do no open source companies admit this? I’ve been drilling open source execs on this point for years – how much of your revenue comes through partners and how much comes directly? Why is it I always get the same answer – “well, we actually don’t get that much revenue from our partners, but they are a really important part of our strategy,” most will say. I spoke with a partner of one open source ERP vendor the other day about partnering with us, and the partner asked me if we were going to force them to sell our Enterprise Version. He told me that his Open Source ERP vendor forces him to do this, but they usually don’t – instead they usually install the Open Source version, charge an installation, and charge the client their own support. No secret there, right? Wrong – this company was listed as a Gold partner for this particular vendor! So do all Open Source companies just suffer from SAP and MS channel envy? Is it really worth the uphill battle?

    3. Enterprise functionality and the balance of power – This is by far the most important point for me, and I believe for almost any open source company. And it is the point that Simon Phipps seems to over simplify while trying to draw ideological lines. The fact is not whether Open Core is good or bad. This type of ideological fanaticism serves no useful purpose. The truth is that “some” enterprise versions are bad and others are not. That’s right – no simple rule. I wish there was one, but there isn’t. The fact is that the Open Core needs to deliver enough value to make sense to enough people. If an open source company “cripples” its open source core, the community will soon head for greener pastures. And the fact is that the successful companies using open core are managing not to cripple their community editions.

    As Mark Radcliffe points out how could open core be doing so much damage to the community version if only 10% of an open source company’s users are using the Enterprise version and the other 90% are using the open source? Good point (although I think this number is actually much less in almost all cases).

    So here is an idea. Instead of worrying about approved licenses and what makes a company truly open or not, let’s just look at the numbers. If more than 10% of a “supposed” open source company’s users are actually paying money and using the software under a commercial license, then that company should no longer be called an Open Source Company. That’s right – they will be banished from this exclusive community. If less than 10% of your users are paying you money, then no worries – you will still have the right to be a card carrying member of the open source software company community.

    So there you have it, if you are an open source software company enjoying revenues in excess of $80 million USD per year – you better watch out because the OSI police are coming to get you because you must be cheating!

     
  • Amy

    Using web services to expand the reach of BPM software

    Amy 12:13 pm on May 29, 2010 | 0 Permalink | Reply
    Tags: bpm software, , business processes,

    In my previous post, I mentioned that many companies are using web services to share business process information among different systems.  So how do web services and business process management software relate to one another?

    In many ways, the goals of BPM software and web services are the same:  to facilitate the flow of business process information from one person or system to another.  As I mentioned in a previous post, many organizations suffer from communicati gaps among people and systems.  Web services provide a solution for people-system and system-system gaps by allowing systems to talk to each other utilizing a common, standard language for sharing information.

    Likewise, business process software allows information to flow freely across systems and departments, and be shared among business processes.  According to pre-defined process permissions, information from one business process can be visible to other departments, and used in other workflows.  Because the process data is not trapped by paper, Excel spreadsheets, or email, it is free to move among workflows, departments, users, and of course, other systems

    So essentially, by using web services in conjunction with a business process management system, business processes can share information not only with one another, but also with other systems.  No process is an island, and often times a business process will involve data from one or many additional systems.  Leveraging web services is an efficient, hands-free way to connect those systems with the BPM, in order to push and pull information during the execution of a business process.

     
  • Amy

    Can you cure a bad business process with BPM software?

    Amy 7:22 pm on May 17, 2010 | 0 Permalink | Reply
    Tags: bpm software, ,

    In my previous post, I went through a number of disadvantages to ad-hoc business processes.  So is business process management software the magical cure for ad-hoc business processes?

    No, yes, and sometimes.

    If you have a weak process design with little documentation and poor performance, slapping BPM software on top will not solve anything.  It might actually make the problem worse by institutionalizing the process failure.  BPM software works best for processes that have been through a “process discovery” phase during which they were thoughtfully considered, documented, and prepared for migration to a BPM software system.  A bad process with BPM software on top is still a bad process.

    But if the business process is mature (i.e. has good documentation, design, and performance), or could be matured relatively quickly, then it may be a great candidates for automation in a BPM system.  BPM software can automate tasks, reduce redundant data entry, save employees from drowning in a sea of paper-based forms, cut Excel and email out of the process, centralize process data, send automatic messages and alerts, and take care of the dirty work so employees and managers can focus on their jobs.  So if a business process is already mature, or can be brought up to speed relatively quickly through process discovery, then BPM software may very well solve its problems.

    Even if you decide to use BPM software, it is important to think about the problems or pain points you’re trying to resolve, to see if your BPM software package is the right tool to solve them.  Take the problem of inflexible IT infrastructure, for example.  A good solution for this problem would be a BPM software tool that allows for DIY process mapping and configuration, allowing managers to modify and improve workflows without requiring heavy IT involvement.  So when looking for a BPM tool, make sure you find one that will makes processes more adaptable rather than more static.

    Likewise, to solve an inefficiency or waste problem, look for a BPM software package with business dashboards and reports, to allow managers to find bottlenecks in processes and forecast and model resources—such as staff allocations for different shift cycles.  A user-friendly BPM system will then allow those same managers to adjust and adapt processes to achieve maximum efficiency and respond to changing business needs.

     
  • Amy

    Some More Key Questions to Ask About Business Process Software - Business Perspective

    Amy 5:20 pm on March 30, 2010 | 2 Permalink | Reply
    Tags: bpm software, ,

    As I mentioned in a previous post, as I was working through my list of the Top BPM Software Pitfalls to Avoid, I also started to think about some of the many questions that organizations should ask themselves when choosing a BPM tool. Again, it is a good idea to consider these questions before you select a business process software in order to help ensure the future success of your BPM system.

    I’ve divided the list into two separate categories: IT questions and business questions. You can find my IT questions here. As I mentioned before, due to the nature of BPM software as a bridge between IT and business, the division is somewhat arbitrary and many of the questions overlap, and should be discussed with members of both IT and business teams.

    Here is a list-in-progress of BPM software questions to consider from the business perspective:

    • What processes would you like to automate?
    • What departments do you plan to implement the BPM software in?
    • Why do you want to use a BPM system?
    • What are your main “pain points” from a business perspective?
    • How do you hope that the BPM system will resolve those issues?
    • Who will be designing the business processes?  A business-user, an external consultant, or an IT-user?
    • Do you need process design consulting?
    • Who will be the end users who participate in the processes?
    • How do you plan to train those designers and end users to use the BPM system?
    • Do you plan to train someone to serve as an in-house process architect?
    • What is your budget?
    • Do you prefer open source software to proprietary software?  Have you considered the pros and cons of each?
    • What language do you plan to use the software in?
    • What level of technical support and training do you require during the process design phase? When the BPM software goes live? In the long term?

    This list is a work-in-progress, and additions are welcome!

     
  • Amy

    Are KPIs Necessary for BPM Success?

    Amy 10:54 pm on March 29, 2010 | 2 Permalink | Reply
    Tags: bpm software, ,

    I’ve received some very interesting comments in response to my previous blog in which I named KPIs as the top BPM software pitfall.  Many thanks to all those who have shared their insights thus far.  I’d like to delve a bit deeper into why I chose KPIs as the greatest business process management software pitfall, and why even despite some very convincing arguments raised by Anatoly, I still believe that KPIs are important to BPM project success.

    I agree that time is of the essence when implementing a BPM software system.  But I am not sure that we are justified in sacrificing all KPIs solely in the interest of time.  First, any quantitative measurement, including ROI and costs, takes time to calculate, and we don’t always have perfect data inputs.  So, while I fully support the idea that efficiency is key, I wonder if we are walking a slippery slope by starting to cut out objective measurements, simply because they take time?

    Taking the efficiency argument a step further, would “time” be a justifiable reason to cut out other key aspects of the BPM software implementation process?  Should we eliminate the process discovery phase?  Or training courses?  Or meetings between management and employees?  I’m not sure I’m comfortable with the idea of short-cutting key phases for the sake of speed.

    Rather, I would argue that the key to saving time and promoting efficiency (both during the BPM software implementation, and in the long run) is to allocate resources effectively and reduce waste, which I believe KPIs (along with other measurements and yes, instinct) can help to reveal.

    Anatoly also makes a convincing argument that in small businesses, the decision-maker’s instincts (coupled with analysis of costs and results) can and should be used in lieu of KPIs.  However, while I agree that instincts are very important, I’m not sure I’m comfortable with the substitution of instincts for real data. As a practical matter, in a small business, where the BPM decision-maker is also the primary project evaluator, the lack of data might not “matter” to anyone.  No higher-ups will ask for BPM data later on, so as long as the decision-maker is “happy”, then the project is “successful”.  However I would still maintain that without some way to quantify and measure the impact of BPM on the company’s performance, we are left without valuable indicators of project success.

    Don’t get me wrong — I don’t suggest we choose hundreds of useless KPIS just for the fun of it.  But by identifying a limited number of specific, appropriate, revealing measurements, I feel we gain valuable insight into our business processes.

    Yes, I imagine that a BPM project can be wildly successful without KPIs.  But how exactly will we know for sure?

     
  • Amy

    Some Questions to Ask When Choosing Business Process Software - IT Perspective

    Amy 8:19 pm on March 27, 2010 | 2 Permalink | Reply
    Tags: bpm software, ,

    As I was creating my list of the Top BPM Software Pitfalls to Avoid, I also started to think about some of the many questions that organizations should ask themselves when choosing a BPM tool.  Considering these questions before you select a business process management software can help pave the way for a successful implementation.  In the alternative, realizing down the road that your software doesn’t serve your own needs can be a complicated (and expensive) mistake.

    For simplicity’s sake, I’m going to divide the questions into two separate lists: IT questions and business questions.  But of course, given the nature of BPM software, many of the questions overlap (another good reason to bring together a hybrid BPM all-star team).  Also, many of these questions should be discussed with your BPM software vendor.

    Here is a list-in-progress of questions to consider from the IT perspective:

    • What is the software ecosystem of your organization?  Which other software systems does the BPM need to connect to now / in the future (for example, ERP, CRM, DMS, etc.)?
    • What databases will you need to connect to?
    • Do you use standard login credentials so your users can log into multiple systems?
    • Will you be using web services to connect to other systems?
    • Will you require some custom development?
    • Will you need to import and export processes?  If so, will to need to use a standard format (like XPDL or XML)?
    • Would you like to be able to edit the software code yourself?
    • Do you prefer open source software to proprietary software?
    • Do you prefer a specific programming language for the BPM software to be written in (particularly if you’ll be making changes to the code)?
    • Will the IT department be responsible for creating and implementing workflows?  Or does the software need to be non-tech-user-friendly so that non-programmers can also design workflows?
    • How many users will you have?  How many will need to be able to design processes?  How many will participate only as end users (filling out forms)?
    • What level of technical support and training do you require during the process design phase?  When the BPM software goes live?  In the long term?
     
  • Amy

    BPM Software Pitfalls to Avoid - Top 3

    Amy 10:53 pm on March 26, 2010 | 9 Permalink | Reply
    Tags: bpm software, ,

    Once you’ve assembled a BPM software dream team, discovered your processes, and automated them using business process software, it’s tempting to believe that your BPM work is done.  Not so!  Here are my top 3 pitfalls to avoid when implementing BPM software:

    3.  Choosing the wrong BPM system

    The BPM software you choose will have an enormous impact on the ease, cost, and sustainability of your BPM implementation. You may want to utilize your “BPM team” to come up with a comprehensive list of requirements, and make sure that the software, and the company that stands behind it, meets those needs.

    Be sure to consider both technical features of the software, as well as the availability of related services such as training (more about this in a second), consulting, technical support, community forums, etc.  Also consider how the BPM system fits into your larger IT infrastructure, at present and with future IT plans in mind.  A software should be stable and powerful, but flexible to respond to changing BPM requirements as well as adapt to an evolving IT infrastructure.

    There are a number of important questions you should ask before choosing a BPM system - far too many to list here. Check back soon for my list of questions.

    2.  Neglecting to train your team

    A key, if not the key, to BPM success is to train your team to take advantage of the system.  It is absolutely necessary to provide training and orientation to the people who will be using the software, as Patrick commented on my previous post.  Remember that end users, supervisors, and process architects will all need training, and may need it at different times, on different aspects of the software, and at differing levels of technical difficulty.

    It is also important to remember that training should cover technical and end user aspects of the software itself, as well as more general BPM topics including BPM strategy, best practices, and of course, pitfalls.  This general orientation helps to give BPM users a framework and perspective from which to approach the BPM system.  Furthermore, management’s goals and expectations should be clearly expressed to end users as part of the orientation process, as I touched on in #10.  During the BPM training, it would also be a very good time to address any doubts, fears, and questions that team members may have about the BPM, as mentioned by José Carlos Gaspar in response to my previous post.

    1. Forgetting to measure KPIs

    It’s easy to take the benefits of BPM for granted. But how will you know your BPM implementation was successful? Before the project even starts, its important to have well-defined, clear indicators that will help measure BPM success. When selecting indicators, its important to choose specific indicators that can be easily measured. For example, its not enough to say “more efficient processing” or “fewer resources”. Rather, select specific KPIs such as “% decrease in average time per case” or “% increase in cases received”.

    Furthermore, baseline indicators need to be established before the BPM system is taken live. If you’ve defined a KPI as “% increase in completed cases per month”, then you need to know how many cases were completed per month before the software was installed. It can be very hard to go back and recreate this pre-BPM data after the software is up and running, so be sure to plan in advance.

    After the BPM system goes live, its important to monitor your results and determine if you are meeting those KPIs. The BPM software should be configured to generate specific reports regarding KPIs, so that bottlenecks can be identified and adjustments made to improve process efficiency. The business process management software you choose should be flexible enough to accommodate changes in process design, so that improvements can be made and optimal results achieved.

    There you have it: my top 10 BPM software pitfalls, and tips to avoid them.  Again, many thanks to those who have commented and shared their insights.  What did I miss?  Is there anything on this list that you would add or change?

     
  • Amy

    Top 10 BPM Software Pitfalls to Avoid - Part 2

    Amy 8:04 pm on March 24, 2010 | 7 Permalink | Reply
    Tags: bpm software, ,

    Earlier this week, I listed some of the top mistakes to avoid when installing and using business process management software.  These common errors can cause major headaches and seriously impact the way that BPM is perceived, used, and leveraged by your organization.  Save yourself the trouble, and avoid the following BPM pitfalls:

    6.  No process is an island

    Once you decide to automate a workflow using business process software, it is tempting to narrowly focus on just the workflow at hand.  But don’t forget that each workflow likely interacts with several other business processes and systems throughout your organization and perhaps beyond.

    Consider an example purchase order request workflow.  The purchase order request may be internal, coming from an employee or department.  Or, it may be external, coming from clients or partners.  If it originates with a client, the BPM software would need to be linked with the website.  If it comes from a partner, it would need to be linked with the company’s CRM system.  Regardless of the origin of the request, it would need to generate a purchase order in the company’s ERP system.  Its important to keep in mind all systems and processes that are connected to a given business process, and never lose the big-picture perspective.

    5.  Don’t tackle everything at once

    Ok, you already know that no process is an island.  But you can’t conquer the whole ocean of processes at once!

    While it’s important to keep the big picture in mind, its equally important to break down the BPM project into manageable phases.  Take it step by step to ensure its done right and learn from your own experiences, applying the lessons learned from implementing earlier workflows to ensure the success of the BPM project as a whole.

    4.  Assemble the right team

    The most successful BPM software implementations are headed up by a dedicated team of IT and business managers leading the charge.  Unlike other software projects, BPM requires business users to collaborate side-by-side with IT to ensure that workflows are properly designed, automated and implemented.  The multi-department team should work together to make sure that the BPM system is aligned with the company’s larger IT and business goals.

    Even if you choose to work with an external BPM consultant to help design and implement workflows, there still needs to be an internal point-person or persons responsible for carrying out the company’s larger BPM vision.  Successful BPM just won’t happen without clear leadership and the merging of business and IT perspectives into one.

    Check back soon for my Top 3!

     
  • Amy

    Top 10 BPM Software Pitfalls to Avoid

    Amy 6:44 pm on March 22, 2010 | 3 Permalink | Reply
    Tags: bpm software, ,

    There are a number of obstacles that can get in the way of business process management success.  If you are considering using business process software in your organization, designing workflows for potential future use, or already using a BPM software suite, be sure to avoid these common mistakes:

    10. Don’t forget about End Users

    As I discussed in my previous blog, it is supremely important for those managers spearheading the BPM software initiative to be in-synch with the needs of those end users who will actually have to use the system to accomplish their daily tasks.  By communicating the benefits of BPM software, and considering the end user experience during process design, management can ensure that BPM software will actually make the end user’s job easier, thereby increasing the BPM software’s utility and benefits to the organization.

    9.  Immature Process Design

    An “immature process” refers to one that is poorly defined, poorly documented, and/or poorly executed.  Without a solid, well-documented workflow design including all the steps, tasks, and participants involved in the process, it is very difficult to automate that process with BPM software.  However, don’t despair!!  The cure for an immature process is “process discovery“, a process of examination, either within the organization or with the help of a process consultant in order to identify and document all of the tasks, steps, and participants for each workflow.

    8.  Happy Path v. Rainy Day Path

    What about anomalies?  When things don’t go as planned, BPM software needs to be flexible and contemplate all possible alternate routes that a case could follow.  During process discovery, its important to go beyond just documenting the “happy path”, or the typical route that a case follows when all circumstances are normal; the BPM software needs to incorporate all possible “rainy day paths” and exceptions.

    Consider the classic example from human resources: the leave application process.  When a supervisor denies an employee’s vacation request form, what happens next?  Does the form return to the employee?  Is the employee notified by email?  What if the employee does not actually take the leave she requested?  A solid, mature process design contemplates all possible “rainy day” circumstances.

    7.  Automate does NOT = Optimize

    Its important to distinguish between “process automation” and “process optimization”.  Slapping BPM software on top of a poorly designed process will not optimize it!  In order to leverage the optimization benefits of BPM software, it’s important for a process architect to consider ways to optimize the process.  By leveraging BPM software features, process architects and process consultants can improve workflow design to eliminate waste, reduce bottlenecks, redistribute resources, connect with other systems, and in turn, optimize the process itself.

    Check back soon for more BPM Software pitfalls to avoid!

     
  • Amy

    Taking the "Human" out of Human Resources Workflows?

    Amy 10:39 pm on March 18, 2010 | 2 Permalink | Reply
    Tags: bpm software, , , , ,

    By taking labor-intensive human resources processes (like a leave application process or expense report process) and automating them with BPM software, HR workflows can become more streamlined, more efficient, and best of all, nearly hands-free.

    But as I wrote about in my last blog post, employees can get confused, upset, and downright scared by workflow automation.  On one hand, management totes the efficiency benefits and savings that BPM software can provide.  On the other hand, managers say “streamline” and employees hear “layoffs.”  And the fear of being “optimized-out” is very real: as I demonstrated in my example leave application process and expense report process maps, a BPM software system can actually replace many of the administrative tasks formerly done by HR employees.

    The point of BPM is to connect people and systems and bridge the gaps between them, not replace humans with machines. That’s why it’s absolutely critical for management to dispel misconceptions and communicate to employees that the BPM software is to help make their jobs easier, quicker, and more streamlined, NOT to replace them with bots.

    Recently I was talking to someone from the human resources department of a bank that had recently installed BPM software.  Unfortunately, no one in her department actually wanted to use the HR workflow software.  Why?  First of all, the employees had not been trained to use the system.  Some were not sure how to operate it, and were reluctant to abandon their paper HR forms for fear that the BPM software would complicate their jobs.  Others feared that the new system would actually work TOO well, and the bank wouldn’t need as many HR employees.  They would be effectively optimizing themselves out of a job.

    It’s true that BPM software allows an organization to do more, faster, with less.  But its important to give employees adequate training, both on how to use the BPM software and on the big-picture goals of the BPM implementation as they fit in with the organization’s larger mission, to dispel any misconceptions and help employees get on board.  Without that orientation and understanding, the BPM software can create gaps, rather than building bridges between people and systems as intended.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel