In the realm of digital transformation, there is nothing worse than implementing a highly sophisticated application that has the potential to greatly benefit the organization but is not accepted by the user base. This is especially true when building Oracle Planning and Budgeting Cloud Service (PBCS) applications – unnecessary complexity confuses the users and does not drive acceptance. Without acceptance, the application gets a bad reputation and is ultimately considered a failure.
Having a straightforward and intuitive application that satisfies all business requirements is vital to addressing user acceptance, which is always a major concern when implementing systemic change. Though every PBCS application is unique, a few best practices could optimize and take it to the next level. This blog is the first of a series that will outline best practices we have implemented with our clients.
There are two principles to help application designers achieve this.
- As obvious as it may sound, PBCS should be used for its intended purpose and not as a transactional or data warehouse.
- Always keep the end user in mind during PBCS application design and build.
Incorporating these best practices will ensure a smoother PBCS deployment and keep users happy.
Best Practice #1 – Use PBCS as a planning and analytical tool, not a transactional or data warehouse
The database engine of PBCS is Essbase which stores all numerical data and performs calculations. When designing a PBCS application, there is a common temptation to push Essbase beyond its limits when it comes to data volume. We won’t get too deep into technical Essbase talk within this blog, but it is important to remember that users of PBCS will likely be interacting heavily with a BSO Essbase database as the backbone of their PBCS app, which is tailored to support quick, complex calculations. With that in mind, the more a PBCS application resembles a transactional system or data warehouse, the longer it takes for the Essbase engine to perform calculations and report queries.
It often boils down to a trade off between level of detail / data volume and overall system performance – the more data that exists in Essbase, the longer it will take to query that data. If stakeholders say that they need transactional level of detail (e.g. to the GL code) or that they require the system to store massive amounts of data, PBCS alone may not be the ideal solution, or at the very least, a separate reporting cube alongside your users primary planning cube may be needed to meet those requirements. If these design considerations are not taken into account, the result could be users experiencing significant performance issues and blaming the tool (PBCS) vs the real issue (application design/usage).
Best Practice #2 – Always keep the end user in mind when designing and building a PBCS application.
The average user needs an application to give them two things:
- Ability to effectively and efficiently do their jobs
- Ease of navigation
One common trap we have seen throughout a PBCS implementation life cycle is focusing too much on creating a complex application to meet the most detailed of business requirements and not spending enough time on how the application will be perceived by the users. Always imagine how a user would navigate through the application. Could the user navigate through forms smoothly? Is it intuitive to use?
There are several ways that PBCS can be utilized to enhance a user’s experience with the system. Tasks lists can be created that walk users through the data entry process in the application while providing them with detailed instructions. You also want to make sure that the designs of your web forms are user friendly and easier to interact with. Additionally, you want to ensure that as you design any tasks lists or form designs, users are able to efficiently use these tools to do their jobs in a more streamlined manner. Remember, user acceptance and the ability to perform jobs efficiently are key determinants in the success of any PBCS implementation. Some helpful ways to enhance the user experience:
- Ad Hoc Templates – these provide users with a good starting point when performing Ad Hoc based reporting.
- Brown Bag Sessions – This is a concept we have deployed with great success on our recent projects. These sessions (held over the lunch hour to avoid meeting conflicts) allow for continuous feedback between the project team and users by offering quick 30-minute sessions that highlight tips and tricks to navigate the system.
- Quick Start Documents – one-page documents that highlight different processes in the application. These are especially helpful when deploying a new feature, or if they are tailored to a more detailed component of using the PBCS application (e.g. allocations).
- Explore Repository – utilize PBCS’s Explore Repository as an ‘EPM SharePoint” to store helpful documents and templates (e.g. Ad Hoc Templates, Quick Start Documents, Training Content, etc).
For next time – Learn about effective change management strategies
A comprehensive change management strategy is also key to a smooth, successful PBCS implementation. Stay tuned for future blogs to learn about developing effective change management strategies and other PBCS best practices.
Now What?
Need some help with building a successful PBCS Application? Connect with our team today.