Well, I am in the middle of my first PBCS implementation and
this is one blog that I really wanted to put down… I wanted to talk about what
a PBCS implementation is actually is like and where exactly in the IT landscape
it fits in. I can be completely wrong in my inferences, so do bear with me. Now
this is not a sales pitch so the truth is that in PBCS development there will
be some days which were very good and we made rapid strides in the application
design and development and at the same time there were other days that were
agonizingly frustrating. Also, do I see benefit in having PBCS? Yes and no.
There is no black and white in this matter. Most of this always boils down to
tradeoff. There would be some cases when PBCS wins hands down but at the other
end of the spectrum, you would have a situation where on premise planning would
be the winner.
So what exactly is PBCS? Well, I could say it is Planning
and Budgeting Cloud service but that really does not capture the essence of
what it is. To be more precise, PBCS is simply a Planning environment that is
managed by someone else (in this case Oracle) that you can use for a small
subscription fees. So where exactly does the benefit come from?
Well, the problem with most data warehousing and business
intelligence projects is that the value of money happens very late in the
project lifecycle. And if something is going to benefit you late in the life
span, it means you need a team that captured all the fundamental assumptions
about your business model in the right place and at the right time. One wrong
assumption or one misstep in requirement analysis, and you are looking for a
sizeable chunk of your investment down the drain with the cost of fixing them
potentially on the higher side of things.
This is exactly where PBCS can come to the rescue. With
PBCS, since it is a managed environment that is given to you, all you have to
do is get your business model in place. No investment in server and database
and the whole baling wire that comes with any EPM install. All that now needs
to be done is get the business model in place. And I can tear down my business
model time and again until I have an application that captures the exact
metrics that I wanted from it. Once the business model is in place, you can
enroll the core set of users who understand the model inside out. This will
ensure that the environment is constantly evolving and the Darwinian principle
kicks in ensuring the best remains and the non-core features get eliminated
out. Since I have an environment that is managed by third party vendor, all
that I as business need to worry about is getting my business model right.
The main disadvantage of PBCS that is see is that since it
is a subscription based system, it will have a tipping point where the benefits
of having a rapid development environment would not be suitable for a huge
budgeting and forecasting solution or if I have a sound development plan for
five plus years. This is bound to happen. The best example I can give for this
is what I call the cab versus car phenomenon. Suppose I travel only by cab and
initially I used to travel only once or twice far apart. In that case, it does
not make sense for me to have a car since I initially have a high cost of
investment involved and that too for a couple of journeys. Now suppose that
travelling by cab takes my fancy and I am regularly travelling in a cab. There
will be a point when the initial high cost of investment is not that high
anymore and I am burning a lot more cash travelling through cab than I would if
I had my own car.
Now, to put in a bit more EPM-ish language, both in-premise
and PBCS are parts of the same ecosystem whose main purpose is to help business
perform better by getting a grasp of their own data and derive meaningful
insights from it. If I have a sound development plan backed by adequate
financial and technical resources and I am pretty sure that all the business
drivers are suitably accounted for in my model, I would strongly suggest to go
for the in-premise application simply because it would allow a lot more
customization than a PBCS application would ever give.
However, if I am not very sure of the business model since
there is a lot of variability or if the initial cost is too high for me, I
would recommend that you go for the PBCS implementation since it will give me
some grasp of the business model and I can have iterative developments planned
to finally reach my desired business state model after trial and error.
This is the first take that I have on PBCS. Comments and
feedback are welcome. I would also be talking about the development team that
is needed for a PBCS implementation, but more about it later.
No comments:
Post a Comment