Two Siebel views, one order

This composite follows a shape that shows up when a small insurance operations team has lived with Siebel long enough to stop trusting it.

Reps wrote quotes in Siebel. A second view, used by the people who checked orders before they went downstream, did not match the first. Nobody had decided that both views were allowed to disagree. It had accumulated: a workflow that set one field, an integration that read another, and a business component users had learned to work around.

The weekly meeting had a spreadsheet. The spreadsheet was the real status. Siebel was where the record was supposed to be.

The project started by naming one path. A quote that should become an order the downstream system would accept. Not every applet. One path. The fields that path depended on, the workflow that stamped them, and the integration that ran when the order left Siebel were traced in that order. Two of those steps were using different meanings for the same status. That was the defect. It looked like a data-quality program until someone read the workflow.

The change was configuration, plus a narrower fix on the outbound mapping. The internal admin sat in the working sessions, so the map stayed with that admin. By the end, the spreadsheet was no longer on the agenda. Exceptions were visible on the order. A bad status could be corrected in Siebel the same day, by the person who would still be there the next month.

Nothing in this example is a published reference. A brochure number — hours saved, revenue recovered — is not here, because a composite should not invent one.

The practice this belongs to is Siebel CRM.