Inside the Briefcase

Augmented Reality Analytics: Transforming Data Visualization

Augmented Reality Analytics: Transforming Data Visualization

Tweet Augmented reality is transforming how data is visualized...

ITBriefcase.net Membership!

ITBriefcase.net Membership!

Tweet Register as an ITBriefcase.net member to unlock exclusive...

Women in Tech Boston

Women in Tech Boston

Hear from an industry analyst and a Fortinet customer...

IT Briefcase Interview: Simplicity, Security, and Scale – The Future for MSPs

IT Briefcase Interview: Simplicity, Security, and Scale – The Future for MSPs

In this interview, JumpCloud’s Antoine Jebara, co-founder and GM...

Tips And Tricks On Getting The Most Out of VPN Services

Tips And Tricks On Getting The Most Out of VPN Services

In the wake of restrictions in access to certain...

BPM: Configuration vs. Coding, Part 2

April 7, 2011 1 Comment

Written by: E. Scott Menter, VP of Business Solutions for BP Logix

Last time I touched on the initial savings realized in the deployment of a configurable (no-code) BPM solution, versus one that requires coding. In today’s post I want to touch on the longer term benefit of using a configurable solution.

Business processes are inherently dynamic. Once the initial deployment of a BPM-based application is complete, there will inevitably arise a need for regular, sometimes urgent updates to the workflows, forms, and rules that comprise that application. As the number of applications grows (as it should, given the flexibility and utility of a good BPM solution), so does the demand for changes. Change creates both risk and expense:

  • Risk. More than one company has been burned when a programmer who created a complex code base departs, leaving behind little in the way of documentation or organizational knowledge of what he has built. In a no-code environment, existing applications are more easily understood, leading to less reliance on individual skills.
  • Expense. Applications built by programmers are maintained by programmers. As was the case in the initial deployment scenario, the use of expensive programmer resources for process maintenance increases costs in two ways: the additional cost of programmer resources versus other, less expensive resources; and the opportunity cost of having your IT team spending time on BPM projects rather than on other efforts where their special skills are absolutely required.

Here’s the tricky part: while the BPM solution your company purchased may have been easy enough to deploy, the maintenance phase exposes its true complexity and cost. Validate the vendor’s claims before you buy by speaking with their existing customers. Find out not only how the customer updates its BPM-enabled processes, but also who in their organization is involved, and what skills those individuals need to have. Listen carefully to their responses before committing: choose poorly and your BPM solution that deployed like a lamb may transform into a lion, mauling your budget and shredding your automation goals.

If you haven’t read part one, you can find it here: PART ONE: BPM: CONFIGURATION VS. CODING

BIO:

Scott MenterE. Scott Menter is the VP of Business Solutions for BP Logix, a provider of business process management (BPM) solutions to corporations, government agencies, and non-profit organizations. Scott is the former head of technology for WaMu Investments, a national retail brokerage. In addition to technology leadership positions he held in financial services and higher education, Scott spent over a decade leading his own identity management software firm. Scott invites you to contact him at Scott.Menter@bplogix.com or on Twitter at http://twitter.com/ESMatBPL.

One Comments to “BPM: Configuration vs. Coding, Part 2”
  1. Suraj says:

    BPM Info ..

Leave a Reply

(required)

(required)


ADVERTISEMENT

Gartner

WomeninTech