Adapt to Curam

The fact that you can customize Curam to do nearly whatever your customer wants is one of its main selling points. However, if you want to get the best value, you'd best avoid customizations as much as possible. Rather, opt for configuration rather than coding.

In short, get the customer to adapt to Curam more rather than getting Curam to adapt to the customer.

Normally, that would be like running towards a brick wall. This is true the older the organization is as they would be set in their ways. However, think of it with different products. Siebel, SAP and other ERP solutions go the other extreme where you are primarily configuring and not much coding. Other ERP solutions force the customers to change the way their organization is run to match what they have built.

Curam, like SAP, Siebel, etc. have gotten experts to take best practices of the social services industry which comes when by their product.

I myself, just see Curam as just a framework. However, I also see it as a best practice reference model ... for the most part.

I am not going to lie to you... the way Curam does things is not perfect. Sometimes things just do not make sense or are just poorly built. However, that does not mean you just junk it. Most of the time there are workarounds that can be applied. You also get access to the support web site in case you have trouble. In which case I am going to list some of the anti-patterns you would encounter. I would delve on them more deeply in their individual articles.

"Client as case"

There is a separation between participant (people, employers, service suppliers) and cases. However, some systems treat them as the same thing. Don't try to merge them, keep the participant management separate from the case.

Out of the box, Curam comes with a participant manager and a case manager. Try to make use of them.

"Everything is case level"

In order to keep things simple, it is easier to just create things and put them in the case level. This is all well and good if the data you are putting in does not change over time. However, most things do change. If you think about it, it is rare that you would have something written on a case that is so permanent that you cannot make changes to it once it is written.

Most of the time, you would want to keep track of those changes as well.

To make it easy on us, Curam out of the box provides support for evidence which loosely follows the Temporal Object pattern.

In short, use the Evidence API. (Performance problems can usually be fixed with strategically created indexes and RUNSTATS, so don't use that as an excuse to not use it).

"Integrated case is there because I have to have it"

The separation between product delivery cases and integrated cases is there for a reason. Don't make the product delivery case. Keep your clients and evidences in the integrated case and manage everything from there rather than the individual cases.

The product delivery case is meant to deliver a product. It pulls information it needs for its assessments from the integrated case.

"The workflow is in the case"

Curam case manager has its own set of states. It is quite tempting to change the states of the case to match your customer's workflow. Try to avoid it. Curam's case and financial manager is tightly integrated with the case status.

However, this is one thing that an analyst/organizational change management has to push in order to make it easier for you to deploy Curam.

"Evidence information goes in the product delivery"

As I said earlier, the product delivery case is for dealing with the delivery of a product and it can pull information from the integrated case or other cases as needed. That being said, think very carefully before you put anything in the product delivery especially anything that is not an automated assessment. Things that users can enter that may be used later on are usually considered evidence which should remain on the Integrated case level.

There should be no evidence in the Product Delivery level.

"Popups everywhere"

Since most pages have names or case references put in them, one usability tip is to link them to the actual page. However, since most developers are not aware of the "Recent Items" they usually just popup a new window to show the related entry especially since there is no obvious way of going back to the case. Here's a tip, put the case that you are currently working on in the "Recent Items" list.

"My own review cycle"

Curam provides a review frequency functionality out of the box with the product delivery.

"Attempt to remove the back button"

Don't bother. Curam already has page expiration. Plus removing it changes the way people normally use the browser making things even more complicated. This applies to any web application, not just Curam.

"Yes/No" codetables

Seriously, trust your users. They can't all be brain dead morons. If that were the case Apple and Microsoft would never have put in the checkboxes as part of their UI specifications. And these are people with larger budgets on UI research than your project.

"Other Concern"

Something to avoid if you can especially for concerns. If you need a concern, create a new one. Even if it is for a prospect.

"Assessment Forms" and "Case decision based on user"

The reason why we move to more automated systems is not so we can do the same thing that we used to be doing before, but improve one what we are doing. "Assessment forms" and "Case decision based on user" are two common things we would find in a Curam application which should really not be there. Assessments and decisions are built into Curam and are usually driven by the rules engine. You should let the users capture as much evidence as needed, but no more. Then let the Curam rules engines determine what the decision and assessments should be. This prevents the developers from having to create complicated input forms and let the forms be generated based on evidence. This is a job of the Change management to make sure that the organization is ready for that move.