RPA is Dead. Long Live Robotic Task Automation

HFS‘s blog “RPA is Dead. Long live Integrated Automation Platforms” was really good, and incredibly thought provoking. So much so they followed it up with a post about how many visitors and shares the blog drove to their site. We agree with many of HFS’s points, however, we feel HFS should have expanded upon some very key things. RPA is great at what it is built for: Task Automation. RPA is not a “Process Transformation” tool, nor will it allow a business to do Digital Business Automation or Intelligent Automation by itself. This should not be surprising. HFS has pointed this out in other blogs but seems to indicate RPA should be capable of more than this in the RPA is Dead blog. RPA is very useful, but it isn’t about automating business processes, it is about automating tasks. RPA isn’t dead, it has just been misrepresented, and needs to be re-named. In other words, RPA is who we thought they were.

Even though RPA is who we thought they were, we strongly believe Robotic Process Automation has a very important place in Intelligent Automation and Digital Business Automation platforms. We have implemented RPA successfully with many of our clients. When approached properly, as part of an overall Digital Automation strategy, it can have incredible ROI, and due to making tasks (with an appropriate fit for RPA) within a process complete much faster and with fewer errors, can greatly improve Productivity. The key words in the previous sentence are “when approached properly.” This is where we believe the disconnect between hype and reality comes in.

One of the first points HFS makes is “RPA hasn’t inspired businesses to rewire their business processes – it’s really just helped them move data around the company faster and require less manual intervention.” This really depends on how a company looks at RPA. Is it a part of an overall Digital Automation effort where companies are looking at their core processes to determine where and what they should transform, and RPA is just a part of their Digital Automation effort? Or, is it “RPA is the second coming and we’re going to apply this everywhere” without any analysis of business processes and how automating certain tasks will effect up and down stream tasks and processes? If it is the latter, then that business is not rewiring (we will refer to this as transforming going forward) their business processes. They aren’t even thinking from a business process perspective. They are thinking from a short-term task focused perspective of replacing head count and lowering costs, rather than the long-term perspective of automating mundane repeatable tasks as part of a Digital Automation effort in order to free their workers for more value adding work, thus helping to transform their processes so they can continue to compete and win in the Digital Age.

In our experience, most companies just aren’t that mature from a business process perspective.  Admittedly we may have a bias here since we approach many things from a process perspective, and are brought in to help companies fix their processes; however, it never ceases to amaze us how many Fortune 500 companies have large portions of their processes paper based and swivel chair, thus greatly hampering productivity. They probably have an Operational Excellence (OpEx) effort, but it isn’t very strong on the process side. For example, we attend and sponsor multiple OpEx events every year and speak with many people at those events. Lately, the two hottest technologies talked about are RPA and AI. The OpEx people themselves are also very interested in process mapping, but the budget they are getting from up top is focused on RPA and AI. However, their processes still aren’t mapped. So, of course they aren’t doing transformation. Transformation is fundamentally about re-engineering processes, and Digital Transformation is about re-engineering those processes with a focus on digitization and automation. If you dive into RPA and AI without understanding your processes, you run the strong possibility of making certain tasks much more efficient without making your overall process more effective, and thus subtracting from overall productivity (Efficiency + Effectiveness = Productivity). Just like with prescription drugs, there should be a warning label on RPA: “Do not implement without understanding RPA is task automation, not business process automation. Failure to do so can result in over expectations, inefficient throughput on processes, millions of dollars wasted, reputation loss and getting fired. In a small number of cases people have grown new body parts. If this happens, please seek immediate help from Salient Process.”

HFS also states “The major issue with RPA today is that it is automating piecemeal tasks.  It needs to be part of an integrated strategy.” Well thank you
Captain Obvious (just injecting a little humor here; HFS does great work, thus the reason we subscribe to their blog). The tool is doing what is was designed to do! While RPA vendors may claim they can solve world hunger, the real sweet spot for RPA is automating piecemeal tasks, thus the reason it should be called Robotic Task Automation, which we’ll talk about more later in this blog. Later in the same section of the blog, HFS states “Forget about leveraging RPA to curate end-to-end processes, most RPA adopters are still tinkering with small-scale projects and piecemeal tasks that compromise elements of broken processes.” To “curate” means to take charge of something. RPA cannot take charge of a process, because RPA isn’t about business processes, it is about automating individual tasks within a process. There is no way RPA can do more than be piecemeal fixes to broken processes. Again, this is what the capability is. It cannot solve problems at the process level, only at the task level, and even then there are only certain tasks within a business process where RPA will help.

Which brings us to the name Robotic Process Automation. Robotic Process Automation is a misnomer. We believe this is a big part of the reason people and organizations are a bit confused with RPA capabilities. RPA does not execute or automate full business processes, nor was it built to. RPA targets individual tasks. Within those tasks its sweet spot is integrating to legacy solutions via desktop apps and screen scrapes, and it is also very good at document management fixes. Whoever came up with the name Robotic Process Automation is a marketing genius. Both Blue Prism in Wikipedia, and HFS in their RPA is Dead blog, lay claim to coining the term. We do not know who the real inventor of the name is. All we know is while it is great from a marketing perspective, the name misrepresents the capabilities, and has caused business and IT (less so due to their understanding of the brittle and band-aid nature of RPA) leaders to think they are taking a process approach while what is really happening is they are automating a small subset of tasks within their processes.

HFS recommends a new name of Robotic Transformation Software. We think that is too wide. Just as with any software, there is a limited set of things RPA can do (it is very good at those things), and “Transformation Software” implies a much wider capability set than RPA can actually deliver. Giving it a name which implies as big of a coverage area as “Transformation Software” will again send Business Units and IT Departments down the wrong path of thinking RPA is a panacea for all of their existing broken processes and integrations. The name implies you can robotically transform anything. RPA can’t. RPA is about task automation, and only certain tasks (i.e. repetitive, manual, non-expert). 

We believe the name should be Robotic Task Automation (full credit: the first person I heard use this term was David Herring of Kaiser Permanente in 2017; I also saw a presentation at BPMNext 2019 where Malcolm Ross of Appian used this term instead of RPA). There is probably a better word than Robotic, but Process within the RPA name is the much more problematic word, so we’ll focus there. For now, we have not heard a better name than Robotic Task Automation. So, we propose to HFS, and all of the other analysts out there: let’s kill the confusion and call it Robotic Task Automation. Part of an analyst’s job is to clarify things (alleviate confusion) for your clients/readers and help them make the right decisions. We agree continuing to call it RPA is misleading and causing many issues. However, as discussed earlier in this blog, changing the name to Robotic Transformation Software would not help. In our opinion, Robotic Task Automation is the best choice.

Lastly, HFS talks about the elements of success for RPA by making the premise “RPA provides a terrific band-aid to fix current solutions; it helps to extend the life of legacy. But does not provide long-term answers.” According to HFS:

The handful of enterprises that have successfully scaled RPA across their organizations have three things in common:

1. A unifying purpose for adopting automation.
2. A broad and ongoing change management program to enable the shift to a hybrid workforce, and
3. A Triple-A Trifecta toolkit that leverages RPA, various permutations of AI, and smart analytics in an integrated fashion”

We agree strongly with HFS that RPA is a terrific band-aid and does not provide long-term answers (sometimes the long-term answer is the wrong answer depending on many factors). We are also aligned on the first two points for success. In fact, you will see some blogs from us in regards to this in the coming weeks. Salient also feels the overall point of the Triple-A Trifecta is headed in the right direction, however it has a major shortcoming in our opinion. The Triple-A Trifecta essentially describes a Venn diagram, or intersection, between RPA, Smart Analytics, and Artificial Intelligence. HFS’s intention with this is to “provide a clear and crisp articulation of the emerging change agents for clients to optimize, renovate, or transform their business operations.” Also, since it is pointed out in the context of the RPA is Dead article, we assume the Triple-A Trifecta should help fix the shortcomings of RPA pointed out by HFS.  However, the Triple-A Trifecta only solves a small portion (Tasks and AI) of  the automation capabilities we feel are necessary to truly achieve a unifying automation vision:

• Process Modeling
• Tasks (RPA)
• Workflow (Structured and Unstructured)
• Decisions
• Content Management
• Data Capture (Structured and Unstructured)
• Governance
• Operational Intelligence (AI)

What the Triple-A Trifecta covers cannot possibly solve is some of the short-comings HFS themselves point out in the RPA is Dead blog, as well as their Seven deadly misnomers of RPA blog. The Triple-A Trifecta is missing everything but Operational Intelligence and Tasks from the automation capabilities listed above. And, as we’ve covered in this blog, RPA is focused on Tasks so it cannot possibly solve the Workflow/Business Process part of the puzzle. It is possible we are misunderstanding what HFS meant by their Triple-A Trifecta. Maybe the Triple-A Trifecta is part of a bigger picture that then encompasses the Triple-A Trifecta. However, we could not find anything in the Trifecta blog indicating this, although maybe HFS thinks this is obvious and self-evident. If it isn’t, then this isn’t a workable approach in our opinion. It is missing the Process (Workflow) piece which HFS refers to repeatedly in the RPA is Dead post. Perhaps HFS can enlighten us in a future blog.

So, there you have it. What do you think of changing RPA (Robotic Process Automation) to be RTA (Robotic Task Automation)? If looks like a duck, sounds like a duck, walks like a duck; what the hec, let’s just go ahead and call it a duck!

IBM Gold Business Partner, Salient Process, leverages proprietary migration tools to improve process applications while improving them

CARMICHAEL, Calif.–March 25, 2019

Salient Process starts off the year by launching TWX Analyzer and TWX Migrator to expedite migration to the latest version of the IBM Business Automation Workflow (BAW) platform, formerly called “IBM BPM” (Business Process Management).

TWX Analyzer and TWX Migrator are proprietary tools that could help customers reduce migration time from weeks to minutes while improving their business applications in the process. TWX Analyzer is an online assessment tool that allows users to upload their process apps and better understand the migration effort required. Specifically, it provides asset counts and reports, identify underlying issues, and formulates a migration strategy on an app by app basis. Meanwhile, TWX Migrator is a migration tool to make quick changes across the entire process application. It automates rework, migrates from old to new artifact types, and cleans up unused artifacts and dependencies.

With many years of experience with BPM at IBM, Jared Michalec, VP Client Services at Salient, recommends that migrations should start as soon as possible to mitigate any possible issues that may arise. “While Salient Process offers several accelerators that can accelerate BPM upgrades/migrations from months to days, there are always unknowns that can pop up.” To make it a no-brainer, Salient provides an online assessment tool for FREE to give clients peace of mind for migration plans. Try it today!

Users can assess their process apps for free on https://www.twxanalyzer.com.

About Salient Process

Founded in 2011, Salient Process is an IBM Gold Business Partner, and a leading provider of IBM Digital Business Automation services and solutions. Salient Process is the creator of the next generation IBM BAW UI (SPARK), and the Quick Process Builder. Providing both software and services for Digital Business Automation, Salient specializes in Robotic Process Automation, Business Automation Workflow (BAW), Content Management, and Decision Management (ODM and DSI). Utilizing a proven and fully documented methodology, Salient partners with clients to ensure they successfully navigate the process and decision-centric maturity journey by not only helping clients build great solutions, but also enabling them to become self-sufficient in workflow, decision, and automation efforts.

Migrations can be tough. Sometimes it can feel like we’re back to the drawing board when things don’t go as planned. Even worse, sometimes it can feel like there is no drawing board to go back to at all. Like a stray dog, the way we approach it will require some strategy and tact – or else we may get bitten. By simply applying the principles of Agile, our migrations can be as smart as our processes. Although this article is in direct reference to the IBM BPM to IBM BAW Migration trend, these principles can be universally applied.

First, we will discuss a few best practices, and then we’ll apply those best practices to their corresponding phase in the Agile Iteration or Sprint. Let’s look at a few recommended best practices to consider as we begin to migrate:

Sift before you shift 

In an ideal world, all your applications are “Lift and Shift” and migrating them will be like an airplane ride you slept through – gracefully awaking on the other side well rested. In the real world, migrations experience turbulence. In the real world, our apps tend to develop idiosyncrasies over time due to an array of factors: workarounds due to product shortcomings, not adhering to best practices, “band-aid fixes”, inexperienced developers, floating business requirements, etc… 

Before we begin to migrate, it’s important to be cognizant and take inventory of all these things. At best, our Migration Plan will account for and correct all these issues. At a minimum, our Migration Plan should prevent any further idiosyncrasies. We want to fully examine the health of our apps before we begin to treat them. Every hour spent planning will pay off in spades. 

For IBM BAW Migrations, TWX Analyzer from Salient Process can help get a bird’s eye view and spot issues in the planning phase. 

Focus on improvement 

Although it sounds a little counter-intuitive, the goal of a migration project is not to migrate, but to improve our applications. After all, the reason for migrating is that the product has been improved (i.e. a new version). Take a step back and analyze the functionality that has been added and/or deprecated. Is anything being removed from the product which your applications relied on? Is anything being added that can make your solutions more elegant? 

Take this as an opportunity to improve problem areas and strengthen your overall codebase / user experience. Since the migration process will require time and materials anyway, you might as well maximize the expenditure. Whatever you do, address breakage responsibly – this is no time for “band-aids”! 

For IBM BAW Migrations, TWX Migrator from Salient Process can help modernize antiquated code, transition to new artifact types, and rapidly apply pattern changes that adhere to best practices. 

Size and prioritize

Consider this a sequel or epilogue to the previous entry – Focus on Improvement II: The Rise of The Realist. We might find that there are more improvement areas than are practical to pursue. In this case, we need to “size and prioritize”.

Keep in mind, there is a difference between improved functionality and core functionality. Assuming these apps are worth their weight in megabytes, the core functionality must be preserved. Thus, the migration duration must be at least long enough to address all of that. Improved functionality, however, will come down to what else fits in the timeline. Once a list of improvement areas has been created, taking the time to estimate each line item and assigning a prioritization will be critical to the user story green-lighting process. Getting teams together to size and prioritize will also help facilitate invaluable conversations which result in unparalleled alignment. And if star alignment isn’t in the cards, team alignment is the next best thing.

If you are unsatisfied with the improvements you’re able to accommodate given the time constraints, don’t overextend the timeline or Bogart requirements. Remember that future iterations are like Paris – we’ll always have them.

Invest in test…ing

Testing is key! Regression testing will be paramount as you move from point A to point B. If you have a vast application landscape and testing seems ominous, consider a slower roll-out strategy. Here’s some good news: regardless of how much you improve / change your applications throughout the migration process, the testing requirement should remain relatively static – another reason to entertain the improvement mentioned in the former section. 

And if you don’t have a good suite of test cases, use this as an opportunity to collect them. 

Drain to avoid pain 

Once your solutions have been migrated and are available to end users, consider draining (old work completes in the old system, new work begins in the new system). It will require some change management to make sure end users are not confused by the dual task lists (two systems); however, the additional complexity of the in-flight migration is often a greater loss in resources than the gain in convenience or clarity.  

Remember that the amount of time your end users will spend with dual task lists is directly correlated to the average cycle time of your processes. This means that, if your cycle times are short, they will end more quickly, thus getting you to a single task list sooner. If the cycle times are long, we will be maintaining two task lists (and systems) longer. Longer cycle times also may put you at a financial disadvantage upholding both support and licensing of two products simultaneously. So, do the math. If the cost to maintain two systems outweighs the cost of the in-flight migration, proceed knowing you made the right choice. 

For IBM BAW Migrations, Process Federation Server can help hide the two task lists making the end user experience seamless while draining – removing the change management component entirely. 

Now that we have a few best practices in the forefront of our minds, let’s walk through an agile iteration step-by-step and look at how it all fits together:

1. Plan 

Much like Sprint planning, we want to examine our backlog, then select a group of stories to tackle. We also want to sift before we shift and add additional work items to the backlog accordingly. An output of this sifting will be a (hopefully short) list of required and optional improvements (focus on improvements) written as stories. Once we have all this information, it’s time to size and prioritize. This is also the time to determine whether draining (to avoid pain) or migrating your instances makes more sense. If draining doesn’t work for you, that’s fine – just be sure to allocate more time.

2. Execute 

Hands on the keyboard! It’s time to develop. As with any development cycle, it’s important to invest in testing. This includes unit testing, user acceptance testing, and systems integration testing when applicable. There’s no way to lose the trust of your end users faster than to roll out a new application that is worse than the previous one. Throughout this phase, remember to focus on improvement. You’ll notice that focus on improvement is listed in both this step as well as the previous. SPOILER ALERT: It will also be in the next. This is because focusing on improvement is not a step, but at the risk of sounding like a yoga teacher, a way of life.

3. Review 

Once your migration has concluded, and the instances are draining (or have been migrated in-flight), conduct a Retrospective. For those unfamiliar, this is when the team gets together and reflects on what did and did not work. Obviously, we want to repeat what did work, and delete what did not. It almost sounds like a… focus on improvement. When possible (i.e. your apps are not intertwined / dependent), roll-out your migrated applications incrementally. This will allow you to reap the full benefits of the Retrospective: responding to your findings and doing an even better job next time around.

The IBM BAW Migration process shouldn’t feel monotonous or obligatory, it should feel exciting. It should feel like a new iteration, because it is. It’s a new chapter. A new start. From IBM Business Process Manager to IBM Business Automation Workflow, and beyond. It’s like a bunch of British chaps on the Mayflower, soon to be pilgrims on the steady shores of Massachusetts. Fast forward several migrations, and America is a thing. But, as Humphrey Bogart might say, “we’ll always have [Plymouth Rock]”.

Over the past 12 months, I’ve attended several business technology events including OPEX San Diego, Forrester Digital Transformation Chicago, RISE Hong Kong and IBM THINK San Francisco.  I have begun to recognize a certain look in the eye of attendees at all those events, almost pleading, “help me understand what is happening.”

When a digital transformational technology or solution emerges, such as digital business automation, most people hit their favorite search engine for analyst reports and white papers, blog posts from trusted thought leaders and case studies, but it’s often not enough to separate the signal from the noise.  It’s often difficult to sift through all the supplier marketing hype and cut to the chase to find real value – not to mention all the negative press on digital transformation failures.

Welcome to the world of Digital Transformation hyperbole.

The opportunities and threats of automation are easy to find in today’s headlines. Some stories make it sound scary; some like a silver bullet.  Themes range from massive job loss to magical front-end customer experiences and back-end operational cost reductions. But the question remains: will automation liberate workers to focus on higher value work or take their jobs?

What is increasingly clear is people are attending business technology events hoping to get a holistic view of what’s real and what’s possible.  They want to separate the FUD from the hope and contribute to the discussion taking place in every organization in the world.

For example, let’s explore Robotic Process Automation (RPA) and its role in Digital Transformation.

One clear event trend is the push toward robotics and robotic automation has everyone scared about job protection.  Employees who designate significant time to manual processes might fear automation due to the threat of losing their personal identity. It is important automation is introduced as something to help those individuals, not to replace their job completely.  There is surely a place for RPA, but one needs to be clear on its limitations.  Like many business initiatives, RPA is often promoted to boost return on investment or reduce costs. RPA can be leveraged to capture and interpret applications, manipulate data, or trigger responses with digital systems.

For mundane, manual and repetitive work, RPA is a perfect fit. For example, replacing/assisting call center agents.  An automated online chat system can reduce the time taken to resolve queries, alleviating waiting times to help ensure a positive customer experience.

RPA is also a great entry point to reduce your systems integrator footprint; where today you may have SI developers as low-cost labor, simply copy/cutting and pasting data.  Prone to human error, this is a perfect fit for RPA.  One Tier One banking CIO I met in Hong Kong stated that they spend over $100M USD in SI services and they were looking to cut that by more than half with a $1M investment in automation technology.  Talk about an ROI!

Automation also has transcendent implications for businesses across the globe, which can free up the time (of humans) to focus on core competencies that directly contribute to the bottom line.  

Before you begin an automation journey, heed this advice shared by many experts:

• Set a clear objective.  Your main objective is to run RPA at scale. If your expectations are out of alignment, RPA can have undesired consequences.  It’s OK to approach RPA with an optimistic mindset, but crucial to keep your eyes open. Approach RPA with caution, and make sure you don’t run before you can walk! The objective of your RPA project should be clearly communicated from the beginning, to ensure everyone is working towards common goals.  If your staff understands the technical and business benefits, you can more easily manage milestones on the route to a successful outcome. Set and manage clear expectations and ensure employee attitudes are in alignment.
• Completely understand the process you intend to automate.  If you only have half-knowledge of something, how do you expect to program a computer to do it?  You should focus on identifying, evaluating and documenting a process before validating and testing it. By this time, you can attempt automation with increased confidence.  Your RPA should be actively used, refined and updated, and continuously updated across its lifespan. This will boost the proficiency of your efforts.
• Focus on the outcomes. Prioritize the importance of productivity gains (efficiency plus effectiveness), while implementing end-to-end metrics to communicate progress. When results improve through automation, staff should be recognized for their efforts, compensated accordingly with an incentive-based reward system.

It can seem as if we’re forever catching up with technology.

Even if your organization is digitally mature, it’s important to realize there is always room to grow. Unlocking your true technological prowess will help you deliver excellence across multiple fields, improving your organizational capabilities.

Salient Process is here to help you “free the humans” no matter what your level of digital maturity, and beyond just RPA, to not only free workers for more added value work, but to enable organizational higher-level thinking (READ: Enabling Higher Level Thinking). We offer Operational Process Excellence solutions as well as business automation accelerators which can help someone in IT, operations or line of business understand what’s real and what’s possible for digital business automation today.  Salient supports a set of tools to include: process modeling, robotic process automation, intelligent content management, business automation workflow, decision management, business automation insights, low code/no code automation, machine learning and more (SEE: Our Story).

But where to begin?

Easy.  We don’t get caught up in the hyperbole as we help our customers focus on the fundamentals – and that’s your process.  And your process is our passion.

Digital Business Automation capabilities now streamline enterprise-wide functions that not too long ago seemed impossible to automate.  But you can’t just perform automation without making sure your processes can function well with automation. After all, making a bad process execute faster only gets you to a bad result that much sooner. Salient Process can help with both Process and Automation. Our combination of services, methodologies and software in concert with understanding your processes, can help you do much more, and more accurately, with fewer resources required. Whether it be rules, process, task automation or accelerators to help your delivery go faster and deliver more ROI, Salient has the answer.

In the words of Mikhail Baryshnikov “fundamentals are the building blocks of fun”.  Let’s Make Digital Transformation and Process Fun Again.

Recently, I read an article from Harvard Business Review on why so many high profile digital transformations fail. The article validated some things I suspected based on observing some of the companies we’ve worked with, or just observing the market in general. It also validated an approach Salient takes to projects which makes sure there are verifiable goals, and that outcomes are tied to the objectives set early in a digital business automation (a sub-set of digital transformation) effort. There are four main points from the article regarding factors of failure in Digital Transformation efforts:

• No company should view digital – or any other major innovation – as their pure salvation.
• Digital is not just a thing you can buy and plug into an organization. It requires investment in various other areas of the business as well, including process.
• Make sure digital initiatives are tied to value.
• If the existing business isn’t doing well, digital transformation is very tempting as something new to solve fundamental problems which may require more than just digital transformation. (One could argue points 1 and 4 are quite similar)

I’d like to focus on tying the digital initiatives back to value factor. While Salient doesn’t typically get involved in corporate wide Digital Transformation initiatives, part of digital transformation efforts usually end up having a Digital Business Automation(“DBA”) component, which is where we play. One of the things Salient does on any project is called a North Star exercise. Essentially, at the start of our effort to map out DBA for a company, this North Star exercise makes sure the DBA effort is tied back to objectives within the company. That there are metrics captured within the process which allow us to measure whether the outcomes from the automated process are moving us closer to, or further away from, the objectives. This is key to success for not just DBA, but digital transformation as well.

From the article:
“There’s something about technological change that causes senior executives in large, established firms to act differently than they might otherwise. When investing in a typical strategic change, managers are usually pretty clear about what they want to accomplish and what it will take to get there. There’s a lot of work to get things right, but they know where they’re going and how to measure progress. If the indicators move in the wrong direction, they can take action to set them on the right path, or can make the choice to de-escalate the investment. With innovative information technology, however, executives sometimes lose their rational decision approaches.”

For DBA, the reason Salient takes the North Star approach is so we know what is important to measure, and that as outcomes are measured, we can determine whether the effort is on the right track or not. Many times, there is only so far you should take a technology. It really depends on what a company is trying to achieve.   This should be determined up front and used as guard rails throughout the DBA initiative. This can be set up as high-level objectives the company is trying to achieve with Digital Automation. These objectives should be business driven, and measurable.

Another advantage of the North Star approach is it is highly driven by customer expectations. Throughout the North Star exercise, the continual focus is on what the customer expectations are and how those can be measured. This hard wires our DBA efforts to value. Salient makes sure the outcomes from the DBA initiative can be measured in such a way that the company knows not only if their company objectives are being met, but customer expectations are being met. Hopefully, the two are well aligned.

North Star is a subset of our Digital Business Automation Methodology. To learn more, click here.

It’s safe to say the energy and excitement level for Salient Process products and our customers’ solutions was at an all-time-high this year at InterConnect 2017. I found myself talking to people in Las Vegas with the same voice as this epic play call, where the announcer caps off a touchdown yelling “What a time to be alive!!!”

For the two weeks following InterConnect, it seems that excitement isn’t going away any time soon and here’s why:

Our new SPARK Ignition product has hit a sweet spot with customers looking to automate their Blueworks Live processes using IBM BPM on Cloud. This product stands out from many others in this “simple process” or “business empowered process development” space for two reasons:

• SPARK Ignition automatically generates a useful process application in IBM BPM based upon Blueworks Live models and documentation
• The artifacts created by SPARK Ignition are true IBM BPM artifacts, including BPDs, human services (client-side or heritage), coaches and coach views, and business objects for process flow. This means there’s no limit to how you extend an “Ignited” process… just flex your IBM BPM muscles like you do today in the Process Designer!

The “SPARK UI getting built into IBM BPM” dream is almost a reality! The recent March release of IBM BPM includes a major feature: built in “SPARK” based UI Events. For the next 3 months, the joint team of Salient and IBM engineers will be focused on finishing this effort to include all of SPARK UI in the next IBM BPM release.

Maybe the biggest news of InterConnect for Salient was the announcement that Salient Process is the IBM Cloud 2017 Smarter Process Innovation partner of the year! We are humbled by this recognition and will continue the hard work and cultivation of partnerships that earned us this award.

If you would like to join in on the excitement, reach out to us at [email protected]!

Salient Process is pleased to announce its continued partnership with IBM on the new IBM Digital Business Assistant product/offering. IBM has been collaborating with Salient Process and a few other select Business Partners over the last few months on its concept, design, and customer targeting. This partnership was hush hush for a while due to the obvious need for IBM to keep this under wraps until they announced the product.

Our Chief Innovator, Eric Ducos, as well as some other members of our team, have had the pleasure of jointly working with IBM through a very unique and intensive partnership that entails joint product design and development, for the last year. We have especially appreciated IBM’s open-mindedness and inclusiveness in approaching problems and finding creative solutions. Salient’s collaboration on Digital Business Assistant has been no different. We feel that IBM’s inclusion of Salient Process and other business partners from its early stages through conceptual refinement, design, and market relevance has been tremendously beneficial for the product and already makes it an excellent fit from the beginning for many of our customers in the various industries we help with Digital Process Automation.

We will continue to partner with IBM either through direct collaborations on innovative products such as Digital Business Assistant and SPARK UI (we have been jointly “blue-washing” in preparation for SPARK UI being built directly into the IBM BPM product in June), or indirect collaborations (we develop but receive feedback from IBM) such as SPARK Ignition. Look for more innovations from Salient Process in the Digital Process Automation area in the future.