What do cars and JIRA have in common? Here in Romania, JIRA has a lot to do with car accidents. Don’t worry, distracted drivers aren’t causing pileups while filing JIRA issues from their mobile phones (at least as far as we know). I used to believe that JIRA is only for building software, but this story – which still amazes me – proves that JIRA can power the most unlikely of workflows.
Years ago, an insurance company acquired a monster enterprise back-office product capable of covering almost any aspect of the insurance business but with a fixed user interface and process. This is pretty standard for insurance companies, but the business had to adapt to the product instead of fitting the product to their company.
Since there was little room to adapt the software, unhappy agents were forced to learn a new process and do extra paperwork to fill the gaps. Productivity was low, and morale was lower. Even worse, the company’s average time to solve a car claim slipped. Slow time to resolution meant the company’s customers – drivers on the road – were unhappy too.
There were no notifications, no queues, and no prioritization. People were dependent on paper-based records. It sounded like a recipe for disaster.
The insurance company started to look for software flexible enough to map their custom process so the software served their company’s needs, not the other way around. JIRA fit the bill. They wanted an easy way to customize their workflows, JIRA had it. They wanted a beautiful web UI, and JIRA had that. They needed an enterprise-grade tool, and JIRA could deliver.
Each car crash report became an issue (after all, car crashes are pretty big issues, right?). The goal was to add agility back into the business, while obeying the rules imposed by the back-office at specific integration gates.
We started them with a very small pilot on JIRA 4.4. For the customization we used JJUPIN, our own add-on, which provides a special scripting language created just for JIRA: the Simple Issue Language, or SIL for short. SIL’s task was to implement whatever task the insurance process needed, and integrate the back-office web services with whatever data was required. In short, the existing software and business process remained the same; JIRA with JJUPIN bridged them together.
Using JJUPIN proved critical because of two important distinctions: First, the language can easily accommodate most of the requirements. Second, it is immune to JIRA upgrades. Scripts are backward compatible, so upgrading JIRA versions has no impact on them.
Delivering the solution quickly was critical too. JJUPIN offers aliases for custom fields, so we could develop on a separate environment then promote the result to test and production systems when ready without changing the scripts. JJUPIN’s extensibility also helped us move fast. We quickly built specific routines to fully integrate the back-office systems with JIRA.
To get a full picture of the scale of the problem, here are some key details:
- Custom fields: over 950
- Instance size: 600,000 issues, 9TB in attachments (lots of pictures of crashed cars)
- Four big workflows: customer center process, damage evaluations, approvals, and payments. Three of them are quite complicated: between 35 and 75 states, between 80 and 180 transitions and between 60 and 120 screens, respectively.
- Claimants are notified either by SMS or by e-mail.
- Automatic fraud detection
We worked together to add more and more of their claim business to JIRA. We started with cars then added (human) bodily injury workflows, and we’re just getting started.
Over the time, we added more SIL-based plugins to our portfolio: Blitz-Actions for scripted modal dialogs in JIRA, KIWI (to deploy JIRA workflows and SIL scripts, from one development JIRA instance to another), and the brand new JJUPIN Agile (that offers support for JIRA Agile).
We proved that JIRA and JJUPIN can power any business process and steer it to success. You’ve got issues? We have JIRA!