TM1 Forum

My issue:

I have disbaled sandboxing in my PM Contributor application so now user cannot create/delete sandbox. Fine
Yet entering data is still marked in blue so is in fact still using the concept of Personal Workspace.

I exit the model and am not prompted to save/commit my changes. Uncommitted data is not in the true cubes so not in the Approval Hierarchy aggregation.
In short, the Central Finance team cannot benefit from ‘early flavour’ reporting as data is held privately until committed.

The sandboxing / personal wokspace of the PM Contributor model is not impacted from the TM1 Architect 'Capability Assignments' – only the ‘Enable Mulitple Sandboxes NO'’ in the PM application properties.

Can anyone help overcome this – to switch off the personal workspace feature.

Thanks

M

Try right clicking on the server name and going to "Capability Assignments". I think this is where you control this feature.

Martin

@M.Ryan

No, already tried that. The personal workspace seems to be just how Contributor apps work by default.

Thanks

Mark H wrote:@M.Ryan

No, already tried that. The personal workspace seems to be just how Contributor apps work by default.

Thanks

"Personal workspace" aka "Sandbox" is just how Contributor is designed to work. There is no way to disable it - all data entry is made in personal workspace and saved to the "base model" only when the user hits commit. That's just how it works plain and simple. You can disable users creating their own additional sandboxes but no matter what you do all the data entry will still be to the personal workspace or "default sandbox". This is part of the design (I believe) to minimize data transactions to the base model and therefore minimize possibility of write locks and contention and maximize concurrency.

You can write directly to the "base model" via other clients, but not via Contributor.

Yes, i understand. Highly disappointing though. This means Cost Centre managers can still 'hide' their workings in private area then surprise Central Finance just before submission deadline. This is not why finance buy the software. It is supposed to limit the 'gaming' of budgeting not promote it. This is the same as keeping the budget in excel then copying to model at last minute.

'Early flavour' reporting enables the company to realise they are falling short of budget/target then take corrective action. If they dont know numbers until last minute they cannot do this.

This is why i was trying to disable the personal workspace or force a commit on exit.



Thanks
M

Addendum

hmmmm. I suppose to solve the 'problem' we could just have more formal budget submissions to force the cost centre managers to commit/submit their plans.

This however does not stop them thinking they have finished the data prep - as s/w doesn't force/suggest a commit on exit.

Thanks all.

M

The whole purpose of Contributor is to provide workflow management. Finance should be able to check the workflow status of any budget node at any time, pinpoint those who haven't submitted, and then send them a nasty note. If you want all budget work to be done online, so Central Finance can see what's cooking whenever they want, then don't use Contributor. It's as simple as that.

Oh, I missed your key point about it being Contributor, not TM1.

You can thank the Cognos guys for this. Contributor was imported from the old Cognos suite and given that they were trying to convince the old Cognos user base to switch over to TM1 it made sense for them to present the product in the same way that Cognos users were used to it. It meant minimal disruption to the end users. Up till that point TM1 had never had a concept of saving. As soon as you typed a number it was in the system. Cognos users weren't used to working this way.

@tomok

I am fully aware of what contributor is as have been working as CP consultant for 8 years.
CP Contributor works in the way i have described above - early flavour reporting to eliminate budget gaming. I was hoping TM1 contributor concept would also have this characteristic, but like promotions i have been disapointed.

Its as simple as that.

@M.Ryan

The ability to save data is a big improvement to TM1 im sure you will agree.
Less.contention and lost data when whole freezes when hit memory limits. Unfortunately the saving is not encouraged by the application.

M

It is possible in EP Contributor for the administrator to disable offline working. This means that saving at the end of an on-line session is the only way. Furthermore even when offline is enabled that is not the normal work mode. The default is to save to the server and when that happens the numbers are available and aggregated up the workflow hierarchy. It takes a specific action to take work offline.

EP Contributor was designed specifically to do away with the budget gaming and to bring visibility to the process. The simplicity of the workflow was deliberate and was designed to encourage visibility. Offline work was not even available until version 3 and it was only put in under duress because it was on the check-box list of so many prospective customers.

@Duncan

Please confirm you are referring to TM1 Contributor. If so can you describe where this 'disable offline working' option is ?

Many thanks.

M

What I said applies to EP Contributor, the product that started life as Adaytum e.Planning. TM1 Contributor obviously uses many of its ideas but it has some significant architectural differences.

Martin Ryan wrote:You can thank the Cognos guys for this.

I just got the feeling that Martin was laying some of the blame for your woe at the door of the designers of e.Planning and I don't really believe that that is fair.

Duncan P wrote:What I said applies to EP Contributor, the product that started life as Adaytum e.Planning. TM1 Contributor obviously uses many of its ideas but it has some significant architectural differences.

Martin Ryan wrote:You can thank the Cognos guys for this.

I just got the feeling that Martin was laying some of the blame for your woe at the door of the designers of e.Planning and I don't really believe that that is fair.

Yes and no. I was pointing out that the characteristic was inherited. Not that it really added much to the conversation. Though we might be able to start another TM1 vs EP flaming war if we try hard enough

Mark H wrote: The ability to save data is a big improvement to TM1 im sure you will agree.
Less.contention and lost data when whole freezes when hit memory limits. Unfortunately the saving is not encouraged by the application.

I agree the ability to choose to work with sandboxes and personal workspaces is an improvement. I disagree that being forced to work this way is an improvement, and I think that's your point too, that it needs to be configurable.

If I were to be forced to work one way I'd prefer that it was saved as soon as I typed it. However that preference is almost certainly because I've been used to working that way for so long with TM1. With your history you may well prefer the opposite.

@Mark H

I wasn't talking about EP Contributor, I was talking about TM1 Contributor. They are two totally separate products and while I'm impressed you have so much experience with EP, I don't see the relevance with TM1 Contributor. Griping about why a product doesn't do what you want it do isn't going to help much. That's why I just gave you the bottom line. I'm sorry that you got your feelings hurt.

@Duncan

Ah. I see. Thanks

@ All:

My final remarks on this: TM1 Contributor is nearly perfect. EP Contributor is nearly perfect. Merge the functionality and it IS perfect.

TM1 Sandboxing:

>Lets CC manager or Sales guy model what-if analysis privately or with customer. Can return to numbers tomorrow as workspace keeps the WIP data = great.
Decide on workable numbers then commit. Great.
>Can keep personal workspace open till last minute = bad.
>Option to remind users of need to commit or forcing commit if sandbox switched off = required.

Thanks all. Very useful to hear your views as always.

Now, I must return to my much bigger issue - designing the TM1 Server setup to overcome the hot-promotion problem. Having to start the 'instance' after promotion to PROD = crashing the entire PROD instance unless we come up with highly tedious process that isn't a process i can ask Ops Team to follow. I'm migrating from CP/EP which of course is simply great at Promotions. Team can currently promote entire 'model' with data without interruoting any other model and ll on the same CP instance. Therefore they are doing this frequently. It helps that i can promote the TM1Contrib model separately so hopefully i can get away with that in most cases.

Best i can come up with this separate instance for Actuals models / forecast models / budget models. Then DEV/PROD for each to minimise down-time. A big change.

M

Yes, I agree the promotion capabilities - or lack thereof - is a massive failing of TM1. They are however finally addressing it with Performance Modeller in 10.1 I see that's the version you've got, so you should have this available to you?

I've not played with it myself yet, but the demo was slick. It raised about a dozen questions for me on how it might work in the real world, but the basic premise looked good.

My own promotion technique to avoid downtime is to rebuild in live whatever I've built in dev. That's often faster than rebooting. Though it is, of course, very bad programming practice and I'll be glad when I no longer have to do it.

@M.Ryan

Yes the PM promotion/transfer wizard works very well. This is designed to migrate 'Contributor' models without data. If we need to promote with data such as PROD to DEV to correct problem on DEV with real data then we still need to use Replication/Synchronisation procedures.

Moving from DEV to PROD should not be big issue as typically we are promoting the design only and do not need to restart service for this.

M