BPM: How many employees does Trustmark have?

Schuster: We have about 2,200, of which about 1,100 are in our third-party administrative business; the balance is in the insurance business.

BPM: Do you have any anecdotes about specific problems?

Schuster: Our CEO is very analytical and detailed, but also very conceptual. Prior to putting in Longview, he would always do cross-checks between the various support departments and business units, asking, "How come this number doesn't match this one?" And the answer was, "Well, they changed it over in this workbook, but the other area didn't change it in their workbook." This kind of stuff was happening every month.

BPM: Did you or anyone in your department spend a lot of time trying to sort these things out?

Schuster: We tried. But it was clear that we were wasting too much time just getting the numbers to match and getting the reports generated. If you really believe that management is about managing your future, then you really need to be able to spend your time focusing on planning and forecasting your future, not "ticking and tying" numbers among spreadsheets.

Of course, planning and forecasting are both about the future. To me, the only difference is that the forecast is the balance of the current year. The plan is what we are actually taking to the board and using to say, "Here is our plan for the next year." Once the board approves the plan in December, it gets locked in, and as soon as that happens we start forecasting the variances to it. We're always forward-looking, with the focus on understanding all of the drivers and their interrelationships. It's pretty much impossible to do it with a PC-based toolset.

BPM: Did you do the variance reporting when you had all of those Excel worksheets? Would you compare actuals to plan?

Schuster: Yes, we had certain standard pages that everyone had to provide. The first one was current month's actuals against current month's plan and the corresponding variances. We had year-to-date actuals against year-to-date plan; year-end forecast against full-year plan; and then an interesting one, current year-end forecast against last month's year-end forecast. This was a standard page that everybody had to do.

Then there was an additional page that showed the current year by month. What are the actuals by month? What are the forecasts by month? You could quickly look at trends -- which things are going up or down, etc.

BPM: It seems to me that consolidating the totals would have been extremely problematic.

Schuster: It was a challenge, and we unfortunately didn't have one repository for consolidated planning, forecasting, actuals, and reporting. Each area was computing their full P&L themselves, and then I had this master workbook where I tried to load them all in and come up with the consolidated totals.

BPM: How do you plan and forecast now, and how have things changed since you implemented the Longview system?

Schuster: The Longview solution gives us a centralized database that we use for our actuals. We load the ledgers into it. It's also where all of our forecasting and all of our planning is done. We have one repository for all the information. It's a six-dimensional database; the difference between plans, forecasts, and actuals is just a change in the "time" dimension. The hierarchy of the reporting and the drivers and everything is the same, so it allows us at a push of the button to have all of the information -- actuals and forecasts -- for the year. Plan, current year plan, next year's plan ... all of this is available. You can click and pull up prior years' actuals; if you want to compare this year to last year, you can do that very, very easily.

The ledgers historically had that capability to do variance reporting and consolidations for the actuals, but to do the predictive forecast and plan calculations to the level we do now with the ledger systems we have wasn't feasible.

We also do our cost allocations in Longview; we take our support area costs and allocate them to the business units. The business units are fully loaded P&Ls. And we actually do multiple allocations. We do allocation of the support areas to the business units, but we do it in a step-down fashion, i.e., the support area costs go to other support departments underneath them as well as to the business units. Each department is allocated individually every month, for actuals, forecasts, and plans, by its own unique driver. So we might allocate HR based on the head count for every department and the IT Help Desk based on the device counts for each department. We then allocate between the business units once they have their fully loaded costs; they support each other, so we have intra--business-unit transfers.

Then we allocate the full cost in the business units to the lines of business within each business unit. For example, the life insurance business unit has multiple products, so we actually allocate costs to each of those products. In our third-party administrator business, we allocate costs out by the various office locations that we have around the country. We do that every month for actuals, plans, and forecasts.

BPM: Were you able to do that kind of allocation when you were using Excel?

Schuster: No. In fact, our allocation process prior to that was done by a mainframe system: a kind of black box. Nobody could understand how the allocations actually worked. It was just "here are the numbers going in, here they are coming out," and just trust that they're right. And nobody did; everyone complained that they were being charged way too much, and we couldn't adequately explain these allocated charges to them.

This new allocation process allows visibility and transparency. You're getting this cost because this is the size of the pot. Here is HR total cost, and your number of employees represent this percent of the total, so you are getting your share of it. Now, you can still complain that it's too much, but at least you know why it is what it is.

To me, allocations are always a case of first assessing the size of the pie and then deciding how to divvy up the pie. We used to spend 90 percent of our time arguing over how to divvy up the pie, and 10 percent on the size of the pie. I believe that it should be exactly the opposite. It should be always: What is the appropriate size of the pie for what we are trying to achieve as a company? How we divvy it up should be pretty straightforward and not a subject of arguments.