I’m wrapping up my TUCON trip with the Colonial Life presentation on their TIBCO iProcess and BusinessWorks implementation in their back office. I work a lot with insurance companies, and find that they can be very conservative in terms of technology implementations: many are just implementing document imaging and workflow, and haven’t really looked at full BPM functionality that includes orchestration of different systems as well as work management. I had a chance to talk with the two presenters, Bijit Das from the business side and Phil Johnston from IT, in a private briefing yesterday; I heard about their business goals to do better work management and improve efficiencies by removing paper from the process, as well as their technical goal to build an agile solution that could be used across multiple process flows. They have done their first implementation in their policy administration area, where they receive about 180k pages of inbound documentation per year, resulting in about 10k work items per month.
They ended up using iProcess primarily as a state management and queuing engine, embedding most of the process flow rules in external database tables, and having just simple process flows in iProcess that routed work based on the table values rather than logic within the process model itself. Once a piece of work ended up in the right queue (or in a user-filtered view of a common work queue), the user could complete it, route it elsewhere, or put it on hold while they performed some activity outside of BPM. A huge part of their improvements came from using BW to create reusable services, where these services could be called from the processes, but they also turned that around and have some cases where iProcess is called as a service from BW for queue and state management, using services that had been developed by Unum (their parent company) for their implementation. They wrote their own custom user interface portal, allowing users to select the queue that they want to work, filter the queue manually, and select the work item that they want to work on. This is a bit unusual for back-office transactional systems, which typically push the next piece of work to a user rather than allowing them to select it, but it’s a lot harder to build those rules when you’re effectively writing all the work management in database tables rather than leveraging work management capabilities in a BPMS.
They transitioned from a very waterfall development model to a much more agile methodology throughout their first project lifecycle, which meant that the business area was seeing the code as it was being developed and testing, allowing for much smoother iterations. Although their first production release took about nine months (after an additional six months to implement the infrastructure), they did their next release in two months. They still do a lot of swivel-chair integration with their legacy policy administration system, and need to build better integration to further improve efficiencies and start to do some straight-through processing.
They’ve seen some impressive improvements:
- The discovery and modeling that happened prior to the implementation forced them to look at their processes critically, and reorganize their teams so that similar work was processed by the same team
- Minimized handoffs have improved SLAs by 4%
- Increased visibility into processes
- Removed 180k pieces of paper per year from the operations area
- 20% efficiency improvement
- Standardized solution for future implementations in other areas
They also learned some lessons and best practices, such as establishing scope, tools for process discovery and brining in the right resources at the right time. Yesterday, when I met with them, I mentioned Nimbus to them, which they had not yet looked at; obviously, they had time to check it out since then, since Bijit called it out from the presentation, saying that it could have helped them during process discovery. Their next steps are to do more system integration to further improve efficiencies by automating where possible, add input channels, and integrate smart forms to drive processes.
Although they have seen a huge amount of improvement in their processes, this still feels a bit like an old-school document workflow implementation, with table-driven simple process flows. Undoubtedly, the service layer is more modern, but I’m left feeling like they could see a lot more benefit to their business if they were to take advantage of newer BPM capabilities. However, this was probably a necessary first step for such a paper-bound organization that was cautiously dipping its toe into the BPM waters.