One of the benefits of being an Oracle ACE is that you get to work on problems that dont just impact a single client but can have a positive impact on a whole community. This week I was speaking to two Oracle executives in my network about unrelated challenges. The first one is why it takes clients so long to develop business requirements when we know what the product is already capable of. The second executive was looking for quantitative benefits of Oracle Cloud Success Navigator (“CSN”). So, to this end, I set myself the challenge of solving both of these problems at the same time.

What is CSN?

What if you could access the experience of over 10,000 Oracle cloud implementations to help you move your ERP system to the cloud? What if you had access to implementation guidance, milestone tracking and tools to help you with your Oracle project? Step forward CSN which you can read more about here. This article is not an in depth review of CSN but does explain how to utilise the AI assist to solve a real world project problem and to quantitatively assess the benefits that CSN brings.

Define the problem

One of the most length activities of building a business case is to derive the business requirements. An ERP implementation could have many hundreds of such requirements often specified using the MoSCoW technique. It is a myth that we don’t need requirements when moving systems to the cloud and I’ve written about this previously. I’m also going to assume that you are familiar with the terminology of MoSCoW r which requires that each statement is either a MUST, SHOULD, COULD or WONT.

In order to run a quantitative benchmark then we need define a clearly stated test. In my experience, the Accounts Payable (“AP”) process is standard across almost every implementation I’ve seen. Within AP there lies something that is even more standard which is the Expenses module. Of course, organisations will have differing expense policies but I find that the underlying requirements vary very little from organisation to organisation.

A benchmark level of effort to derive a set of MoSCoW requirements for expenses would typically be four client side people from various parts of the organisation facilitated by a business analyst in a workshop from, say, 10am to 4pm. Lets say 5 hours of 5 people (25 hours) plus 2 hours preparation. This gives us a baseline of 27 hours in total. Let’s see what CSN can do…

CSN produces a requirement specification

The Right Hand Side of CSN looks like this:

We then click on the Red and White icon which is the AI assist and get started:

I then dive in with the following query:

Not a great start. However, AI assistants are only as good as the query you use so I come at the problem from a slightly different angle:

This time CSN hits the target and I get the following:

1. Employee Expense Submission: Employees can create and submit expense reports for business-related costs such as travel, meals, and lodging.
2. Manager Approval Workflow: Managers review, approve, or reject submitted expense reports, ensuring compliance with company policies.
3. Policy Compliance and Audit: The system automatically checks expenses against company policies and flags non-compliant or duplicate expenses for audit.
4. Receipt Capture and Attachment: Employees can attach digital receipts and supporting documents to their expense reports for verification.
5. Corporate Card Integration: Corporate credit card transactions are automatically imported and matched to expense reports for streamlined reconciliation.
6. Mileage and Per Diem Calculation: The module calculates mileage reimbursements and per diem allowances based on company rules and travel details.
7. Multi-Currency and Tax Handling: Supports expenses in multiple currencies and calculates applicable taxes for global operations.
8. Reimbursement Processing: Approved expenses are processed for payment through integration with Accounts Payable.
9. Analytics and Reporting: Provides dashboards and reports for spend analysis, policy violations, and reimbursement trends.
10. Mobile Expense Management: Employees can submit, approve, and track expenses using mobile devices for greater flexibility.

The wording certainly hits the mark of the output I could expect from the workshop I’ve described above. However, I then think how many requirements should I expect to see for expenses. To this end, I looked back at a requirements catalogue from a previous implementation which had nine for expenses. So this is OK. However, I then notice that the AI assistant has prefaced the above list with the following words:

“Here are some key use cases for the Oracle ERP Expenses module:”

The use of the word “some” implies “not all”….so I ask the AI assistant a more targeted question to provide “a comprehensive list of requirements”. I get the following:

1. Employee Expense Submission: Employees submit expense reports for travel, meals, lodging, and other business-related costs.
2. Mobile Expense Capture: Employees capture and submit expenses using mobile devices, including photo capture of receipts.
3. Receipt Management: Attach, scan, and manage digital receipts for expense verification and audit.
4. Corporate Card Integration: Import and match corporate credit card transactions to expense reports.
5. Automated Policy Enforcement: System checks expenses against company policies for compliance (e.g., spending limits, allowed categories).
6. Approval Workflow: Multi-level approval process for submitted expense reports, including manager and finance review.
7. Per Diem and Mileage Calculation: Automatic calculation of per diem allowances and mileage reimbursements based on company rules.
8. Multi-Currency and Tax Handling: Support for expenses in multiple currencies and calculation of applicable taxes (VAT, GST, etc.).
9. Project and Cost Center Allocation: Allocate expenses to specific projects, departments, or cost centers for accurate financial tracking.
10. Audit and Fraud Detection: Automated and manual audit processes to flag suspicious or non-compliant expenses.
11. Integration with Accounts Payable: Approved expenses are processed for reimbursement through the Accounts Payable module.
12. Cash Advance Requests and Settlement: Employees request cash advances and settle them against incurred expenses.
13. Delegate Expense Entry: Allow assistants or delegates to enter expenses on behalf of other employees.
14. Expense Report Resubmission and Correction: Employees can resubmit corrected expense reports after rejection or audit queries.
15. Expense Analytics and Reporting: Dashboards and reports for spend analysis, policy violations, reimbursement trends, and audit outcomes.
16. Automated Duplicate Detection: System flags potential duplicate expenses or receipts for review.
17. Integration with Travel Booking Systems: Sync travel bookings with expense reports for seamless reconciliation.
18. Expense Category Management: Define and manage custom expense categories and subcategories.
19. Notification and Alerts: Automated notifications for pending approvals, policy violations, or missing receipts.
20. Role-Based Access and Security: Control access to expense data and actions based on user roles (employee, manager, auditor, finance).

This is now the most comprehensive set of requirements I’ve seen associated with an ERP project- 120% more than I had seen on an average real life ERP project.

The timings are then “off the charts” by comparison. This took me 10 minutes to create a list that could have taken 27 hours of effort which, on the face of it, is 162 times more productive (27 divided by 0.16666). To validate this number, I need to check that I’m being as honest as I can be with the comparison. Yes, it would take five people five hours to get the same result, However, one of the benefits of the face-to-face workshop would be that everybody would have been involved in the synthesis of the requirements and will have verified them within the session. So, in order to verify the CSN produced requirements, I’m thinking we need 1 hour of the four people’s time back to buy into the above list of 20 items. This gives me a ‘true’ ROI of (27 divided by 4.16666). From which I conclude that CSN is a factor of 6.5 times more efficient at deriving business requirements which is certainly a quantifiable benefit of using CSN (the second of the two problems we set out to solve).

In addition, we have also solved the first problem by stating the requirements of a Enterprise Class ERP system for Expenses Management- and we’ve done it 6.5 times more efficiently. The next steps here is to undertake a piece of work to document the other areas of AP as well as Accounts Receivable, Fixed Assets, General Ledger, Project Management etc so that we have a comprehensive catalogue of a full set of client needs.

Follow on work for CSN

CSN also indicated it would be able to help me with Expenses Management for process mapping, test management and other aspects of the project lifecycle which I will explore in future articles.

Great to spend time with a world class University today to go through the experiences of getting ERP to the Cloud.

Embarking on an Oracle ERP implementation can be one of the most challenging experiences in a professional career. These projects are often large in scope, with complex integrations, tight deadlines, and a wide range of stakeholders. For individuals on the project team, the sheer volume of tasks, dependencies, and shifting priorities can feel overwhelming. However, with the right approach and tools like JIRA, you can regain control of your workload and navigate the chaos more effectively.

Why Oracle ERP Projects Feel Overwhelming:

1. Multifaceted Scope – Oracle ERP projects typically span financials, supply chain, HR, and more. Each module has its own requirements and timelines.
2. Tight Interdependencies – A delay in one stream often causes a knock-on effect elsewhere, adding pressure and stress.
3. Continuous Change – Stakeholders frequently update requirements, meaning priorities can shift overnight.
4. High Documentation Load – Testing scripts, configuration documents, and integration mappings can quickly pile up.

Leveraging JIRA to Manage Your Individual Workload

While JIRA is often used for team-level project management, it can be a powerful personal productivity tool in large ERP programmes. Here are key features and strategies:

1. Personal Boards and Filters
   • Create a Kanban board filtered to only show your tasks. This gives you a clear at-a-glance view of what’s in progress, blocked, and completed.
   • Use swimlanes to split tasks by module or priority, helping you focus on the most critical items first.
2. Sub-Tasks for Complex Tasks
   • Break down major deliverables like a configuration pack or a test cycle into sub-tasks. Tracking these smaller steps reduces mental clutter and gives a sense of progress as they are completed.
3. Custom Dashboards
   • Set up a personal dashboard to track items assigned to you, upcoming deadlines, and blockers.
   • Include charts for workload distribution and priority levels to better plan your day.

1. Labels and Components for Clarity
   • Tag your tasks with labels such as “Finance”, “Integration”, or “Testing” so you can quickly filter and focus on related work. Personally, I’m not a fan of labels. Labels can cause problems because the individual users can add, for example, #Accounts Receivable; #Account Receivables; #AR etc. When building a dashboard or a filer then spelling mistakes in the labels result in tickets being missed. A more reliable way is to create a custom field with a series of specific values that the user selects from
2. Automation for Notifications
   • Use JIRA automation rules to notify you when a dependent task is completed or a blocker is resolved.
   • This prevents constantly checking for updates and reduces the risk of tasks slipping through the cracks.
3. Time Tracking and Estimation
   • Logging time and setting realistic estimates can help you visualise workload and communicate capacity to your project manager.

Bringing It Together

An Oracle ERP project doesn’t get less complex just because you’re organised—but your experience of it can improve dramatically. By leveraging JIRA not just as a project-level tool but as a personal task manager, you can:

• Prioritise with clarity
• Break down intimidating deliverables
• Track progress without losing sight of dependencies

In the midst of an overwhelming ERP programme, JIRA’s personal boards, dashboards, and automation features can give you the breathing room to stay productive and maintain your sanity.

Implementing an Oracle ERP (Enterprise Resource Planning) system is no small feat. It demands meticulous planning, cross-departmental collaboration, and the ability to navigate complex challenges. While the primary aim is to streamline operations and integrate data across the organisation, the process itself is a powerful lesson in problem solving. The principles and techniques used to successfully deploy an ERP system can be applied to a wide array of other problems, both in business and in life.

1. Break Down Complex Problems into Manageable Parts

One of the first lessons from ERP implementation is that large, complex problems are best tackled in smaller, structured components. Oracle ERP systems touch finance, supply chain, HR, and more. Attempting to handle all configurations and integrations in one go is a recipe for chaos. Project teams often divide the implementation into modules or phases, focusing on one area at a time.

Lesson for broader problem solving: Any daunting issue can be decomposed into actionable segments. Whether you are developing a new product or resolving a team conflict, clearly defining the individual moving pieces makes progress more achievable and less overwhelming.

2. Invest in Thorough Preparation and Planning

ERP projects succeed or fail in the planning phase. Organisations that rush into configuration without mapping out existing processes, data flows, and future requirements frequently hit roadblocks. Successful implementations involve months of requirement gathering, stakeholder interviews, and process documentation before the first line of code is touched.

Lesson for broader problem solving: Preparation is not wasted time—it is the foundation of effective problem solving. Before leaping to solutions, take the time to understand the landscape, gather data, and identify potential risks.

3. Engage Stakeholders Early and Often

Oracle ERP implementations affect nearly every part of an organisation, which means ignoring stakeholders leads to resistance, errors, and rework. High-performing project teams involve finance managers, HR leads, and operations staff from day one, ensuring that the system will serve their needs and that they feel ownership of the final result.

Lesson for broader problem solving: Problems rarely sit in isolation. Whether in business or community initiatives, involving all relevant parties from the outset reduces friction, surfaces blind spots, and fosters solutions that are more widely accepted.

4. Embrace Iteration and Testing

ERP systems cannot simply be installed and left to run. They require rigorous testing in sandbox environments, followed by adjustments based on user feedback. This iterative approach allows teams to catch errors early and refine configurations before full go-live.

Lesson for broader problem solving: Iterative problem solving—testing, learning, and adjusting—is far more effective than seeking a perfect solution on the first attempt. In any project, creating a feedback loop and being willing to adapt is key to long-term success.

5. Anticipate Resistance and Manage Change

Even the most technically flawless Oracle ERP implementation can falter if users are resistant to change. People are naturally inclined towards familiar systems and routines. Successful ERP projects incorporate change management: clear communication, regular updates, training sessions, and support structures that help staff transition smoothly.

Lesson for broader problem solving: Human behaviour is often the hardest part of any problem to manage. Solutions must account not only for the technical or logical aspects but also for the emotional and cultural dimensions of change.

6. Document and Learn from the Process

ERP implementations generate extensive documentation—process maps, training manuals, and lessons learned. This not only supports current operations but also provides a reference for future challenges.

Lesson for broader problem solving: Documenting your findings, decisions, and results reinforces learning and aids continuous improvement. When tackling other complex problems, keeping clear records of what worked and what didn’t accelerates progress next time.

7. Celebrate Milestones and Recognise Success

Large implementations can span months or even years. Recognising achievements along the way—completing data migration, finishing a round of testing, or going live with a new module—keeps morale high and reinforces the team’s commitment.

Lesson for broader problem solving: Breaking down challenges into smaller wins and acknowledging progress helps maintain momentum and motivation, whatever the problem at hand.

Applying ERP Lessons to Everyday Problem Solving

The implementation of an Oracle ERP system is a masterclass in structured, collaborative problem solving. By breaking down complexity, preparing thoroughly, involving stakeholders, iterating solutions, managing change, documenting lessons, and celebrating progress, organisations develop disciplines that extend far beyond software deployment.

Whether you are reinventing a business process, designing a new product, or navigating personal challenges, these same principles can guide you to clearer thinking, stronger actions, and more sustainable outcomes.

Complex problems may feel unique, but the methods for solving them are universal—and an ERP system is proof that even the most intricate challenges can be conquered with the right approach.

70% of ERP projects fail; 25% of them fail catastrophically (L. Clark, The Register 2025). Those figures are alarming enough but it gets worse when you consider the consequences. If we consider a “mild failure” then we could expect to see a two to six month over run which, assuming a cost expenditure of $1m/month then this equates to between $2m and $6m cost over run. I would also advise clients to put aside enough funds for a six month over run- “just in case”. If you consider Birmingham City Council to be at the other end of the spectrum then we are talking about a project that planned to cost £20m actually costing nearer £170m or eight and a half times the original cost (L. Clark, The Register 2025).

The good news is that there a relatively small number of things that can go wrong and all are avoidable. At the heart of the project are four pillars that we need to manage:

• The timeline
• The scope which includes the benefits and requirements catalogue
• The testing of the system to ensure we go-live with quality built in
• The resources involved (project team; end users and suppliers)

Let’s consider the top 3 threats to each in turn:

Timescales

The project plan forecasts when the new system will go-live. At the most granular level, it tells us what tasks need to be accomplished each day and the milestones tell us whether we are on track or not. The go-live itself is the culmination of a large number of interlocking activities that are highly dependent on other activities. Should something change then the dates can move- sometimes for the better but often for the worse.

The top 3 risks to manage against the timeline are: 

• Underestimating how long each activity takes. This occurs because people can lack experience of the delivery of such projects and simply get their forecast wrong. In an ERP project, a task that should take two days can often take five to ten days to ensure that everybody who needs to be involved in the task has been consulted. Building the correct review times into such activities is a key mitigation

• The dependencies themselves are key. Often dependencies are missed and key activities or even phases of work such as End User Testing can’t start because a key pre-cursor wasn’t identified. This can lead to unnecessary stand still on a project that can be burning $1m/month

• Change to the scope of the project is inevitable. On an ERP project we might anticipate 40-60 such requests for change. Not all of these result in an increase in cost but they can affect the timeline. It is crucial that any changes to the scope are considered before being agreed to. The good news is that implementing a robust project change management approach is fairly simple to do- but it needs to be done early and everybody involved in the project needs to be onboard and involved with this process

Scope

ERP projects are not cheap and it is likely that a business case was needed to be written and approved to release the investment funds required. The business case will have highlighted the benefits of the project which, hopefully, will include tangible financial savings to the organisation. Alongside the business case will be the need for a clear definition of scope of the project which should include a catalogue of business requirements.

The top 3 risks to manage against the scope are:

• Not realising the benefits. This often occurs because there are gaps in the requirements catalogue and/or that the requirements are not traced back to the benefits. Discussed above is the need to manage change of scope and a key failing of a project during the design or testing phase is to descope a requirement without understand the impact it could have on the benefits that have been signed up to.

• Finance ERP systems are renowned for needing a large number of technical integrations with other systems. These can be “up stream” systems that have inbound interfaces into the ERP system or “down stream” systems that have outbound interfaces from the ERP system. The technical integrations that need a disproportionate amount of attention are the systems that have “two way” integrations. The most common of these is if there a separate Customer Experience System (“CX”) that sits outside of the ERP platform. Such “two way” integrations are not just twice the risk of other “one way” integrations but more likely to be four or eight times more risky.

• Focusing on the technology and not the business process itself. Yes, an ERP project is a huge technical undertaking but not understanding the impact the new system can have on the underlying process can often lead to business disruption after go-live

Quality

Testing the system is key. Technical Interfaces are rigorously tested as part of the System Integration Testing (“SIT”) and User Acceptance Testing (“UAT”) is there to ensure that each business requirement is met at that the system supports the end-to-end business process. The ERP system itself will have been thoroughly tested by the software provider so we have a look a little deeper at where the quality threats come from.

The time 3 risks to manage against the quality of the system are:

• Data Migration. ERP systems have robust workflows to allow data to be created (e.g. setting up a new supplier). There is then a technical term called “referential integrity” to ensure that data from one part of the system corrects correctly to data in another part of the system. An example being when a Purchase Order is created against the supplier that we also set-up in the system. This flow continues with the Goods Receipt Notice; the Purchase Invoices and the payment notification. If all the data was created directly in the ERP system then we would have a much simpler project. However, at any given point, there will be open Purchase Orders; goods in transit; good receipted but not paid for etc etc. In practice, we are required on an ERP project to migrate different types of data from the old system to the new system. We now have the added complexity, for examples, of testing whether we can create a new Purchase Order in the new system linked to a supplier’s details that have been migrated over. It is critical that the migrated data used for UAT is super clean (Circa 95% correct). Getting data migration right is extremely tricky and should have a project work stream all to itself.

• Reporting requirements are not met at go-live. ERP systems come with a large number of reports and dashboards out-of-the box. However, every organisation runs their processes slightly differently. This results in reports often needing to be amended or new ones created. New ERP systems bring new ways of visualising the data and this often reduced the number of reports required. It wouldn’t be unusual to have 600 reports on the old system that become whittled down to just 60 reports on the new system without losing anything. This is quite a transformation and getting this right should have a project work stream all to itself 

• Product defects in the cloud based system. ERP systems are Common Off-the-Shelf (“COTS”) software packages. If the software selection has gone according to plan then there should be between 85-90% match of the business requirements with the out-of-the-box system. However, there are no guarantees that the new software will be glitch free. At the time of writing, software providers are busy creating quarterly upgrades with new Artificial Intelligence features. The software doesn’t stand still and there is always a risk that new features dont work for your given use cases or that these new features have had an unintended consequence on existing features. Such issues are rare but do need to be managed with the software supplier to ensure that there are no unnecessary delay. Having a representative of the software provider on the project board is a key mitigation.

Resource

ERP projects not only need an army of people (which is where the costs come from) but also highly skilled people – include existing people in the organisation who have a deep understanding of how the processes work across the organisation.

The time 3 risks to manage against the project resources are:

• Resource availability. This can manifest itself in a number of ways. For example, there maybe a certain skill that is an organisation doesn’t have a lot of (e.g. Sales & Purchase Taxation processing). Assume that there is only one person in the organisation with this skill and they have a busy day job as well as needing to be available for the project. Also, the project Subject Matter Experts (“SMEs”) are fully utilised on the projects and there are pinch points on their time across the project. This is particularly a problem if some activities become delayed and the original resource profile changes. For example, an SME might need to work on the review of training material at the same time as supporting SIT execution and UAT preparation. These activities creates a very timetabled schedule and problems with any of these work streams can knock the timetable out.

• Resistance to change. ERP systems are not replaced very often- as much as once every 20 years. So people across the organisation get very familiar with their ways of working. The pain points that we are trying to get rid of in the old system have simply become accepted workarounds over the years. Managing the business change should have a dedicated project work stream to manage this risk.

• System integrator performance issues. The System Integrator market place is exceptionally mature with each of them having well refined accelerators in order to get the new ERP system delivered as speedily as possible. However, these methodologies are only as good as the people using them. System Integrators need people with a plethora of skills such as ERP technical skills; good at people management; an understanding of the underlying industry sector for the implementation; project management disciplines as well as a working knowledge of the system integrator’s accelerator product. It is key that there is an escalation process in place with the system integrator to ensure everything runs smoothly and that issues are dealt with quickly and effectively. 

Background

One of the benefits of working in Higher Education is that you are surrounded by academics who are always looking for data to analyse. An ERP implementation in a University provides much data for academics to chew over, analyse, summarise and publish to the wider community. 

You would think that everything that could be said about ERP implementations was said long ago. However, this is a review of a paper from as recent as 2024 from two academics (Kevry Ramdany and Asniati Bahari) in the Faculty of Economics and Business at the Universitas Andalas in Indonesia. They looked at a single ERP project in West Sumatra and used a research technique of interviewing key stakeholders to draw out the key themes that shed light on Digital Transformation.

Academic papers have a strict layout and way of doing things that can often result in a difficult read. However, I aim to use my academic background to help cut through the density and to present the key pieces of information that will help you with your own digital transformation

What does the paper say?

The first two findings are not surprising:

1. Plan carefully and prepare (including the selection of modules you want to use, outreach and training)
2. Reduce risk through a phased approach (configuration, data migration, sequential launching)

One aspect of the paper’s findings is the early socialisation of the system through seminars, workshops and presentations. From my own experience this can be a tricky one to pull off. In the early days of the project lifecycle you don’t have all the key features working and, without migrated data, the experience of the system can be less than compelling. However, I’m an advocate of starting to tell the story early and demonstrate how intuitive modern systems are. Ask yourself, “when in the journey will we be getting in front of schools, faculties and departments to tell the story of our ERP journey?”

Challenges faced

The paper calls out two key challenges faced by this particular project

1. Resistance to change
2. Budget limitations

Regarding resistance to change, the key point that the paper makes is the lack of technical skills among staff and lecturers and that comprehensive training is critical.

For budgetary limitations, the paper specifically quotes one of the participants who took part in the research:
“After implementation, universities must consider the costs of maintaining the ERP system, including technical support, software updates, and system security. These costs may vary depending on the complexity of the system.”

It is certainly true in my experience that many projects focus on the cost of implementation and often do not factor in the required cost to manage ongoing change. Ask yourself, “have we set aside enough in the business case for post go-live support?”

Factors for Successful ERP Implementation

The paper focuses on 3 key success factors for people to take into consideration:

1. Management support (including the allocation of adequate resources for the project and active support to overcome obstacles during implementation). The paper also references the need for project leadership to being experienced in the relevant technology as well as an understanding of University operations.
2. User Engagement (including serious consideration from end users in the planning and implementation process)
3. Careful planning stating that “a detailed implementation roadmap is essential”. This helps with regular reviews of milestones and budgetary expenditure.

Impact of ERP implementation on Operational Efficiency and Service Quality

The paper looks at the the success of the project through interviews finding, for example, “a faster and more structured registration and payment process”. I know we often seek to have a business case with benefits that are quantitative and cashable. However, I would suggest that the starting point for any such project is the qualitative approach that we see in this paper and many others:

1. What pain points with this project remove?
2. After go-live, simply ask the question of the functional managers (accounts receivable, accounts payable, collections, cash management, fixed assets, general ledger) what service improvements are we seeing?

The paper concludes with the key points that becomes your key take-aways:

1. Plan carefully and prepare for adoption (module assessment, outreach and training)
2. Implementation should be phased to help manage risk
3. You will see a positive impact on operational efficiency and service quality through process automative, data Integration and access to information
4. Adopt a strong communicative approach to overcome resistance to change
5. Invest in comprehensive training on how to use the system (referred to as “technical” training)
6. Effective and transparent budget management is a priority with sufficient resources both for implementation and long term maintenance
7. Plan to continuously evaluate and monitor the system after go-live

Formal Reference of the paper

Ramdany, K., & Bahari, A. (2024). Digital Transformation in Higher Education through the Implementation of Enterprise Resource Planning. JOURNAL OF APPLIED MANAGERIAL ACCOUNTING, 8(2), 310–319. https://doi.org/10.30871/jama.v8i2.8454

Link to the actual paper

The paper can be found through Google scholar at no cost and is available at the Journal of Applied Managerial Accounting.

https://jurnal.polibatam.ac.id/index.php/JAMA/article/view/8454

With the keywords

Digital Transformation, Higher Education, Enterprise Resource Planning (ERP), and ERP Implementation

This article is for you if…

..you manage technology and are involved in a project or programme and you are afraid to ask ‘who is suppose to be doing what?’

Or

…if you are regularly involved in technology change projects and you need a resource to share with your clients or internal customers because they keep asking you questions that are better answered by somebody else in the project team.

References

https://sfia-online.org/en

Background

If you run a function that is about to or is going through a significant amount of change

Change either happens iteratively and continually or in a big step such as through a project or a programme. You are probably involved in continual change all the time either helping people develop their skills, tweaking a process or procedure and making small changes to reports or the systems that you use. However, when a project or programme comes along it usually accompanied by help from outside the function or organisation. 

Technology change projects can bring with them a bewildering number of people that have opaque job titles who seem to know what they are doing and you are probably wanting to ask “what exactly is it you do?”. This article helps you understand exactly what each job is designed to do and who you need to go to so you can find answers to your questions without being given the runaround. It explains who is on the hook for what and what outputs you can expect from all of these strange people that have invaded your space.

If you help deliver change

If you are involved in projects and programmes all the time you probably take for granted what everybody does. However, it recently came to me as a shock that one of my senior clients wasn’t aware of the differences in the key roles. So, if you are involved in the delivery of technology change then you can use this article as a resource to share upfront to demystify what it is you do.

How this article helps

The good news is that there is a really helpful online resource that is free for you to access for your personal knowledge, that is well laid out and can help you cut to the chase. What is even more surprising is that most people involved with technology don’t know that this resource exists.

The bad news is that we often see ‘hybrid roles’ where people describe themselves as having a mixture of skills but we will get to this later.

The theory

The online resource is the Skills Framework for the Information Age (“SFIA”) and is the management system that you probably haven’t heard of. It defines the skills and competencies required by people who manage and protect the data and technology that power the digital world (SFIA Website). The people who are aware of it treat it with great affection and often call it ‘Sofia” or even “Sophie”. It is a relatively modern management system introduced in 2000 but is already on its 8th version. 

So how does SFIA it work? 

SFIA has a series of skills (think of them as job families) – for example, Information Security. For each skill, there is a ladder of seven levels starting at level 1, the lowest, going up to level 7, the highest. The levels are summarised as:

SFIA describes not only the autonomy but also the level of influence for each level as well as the complexity, business skills needed, and the knowledge required to perform at that level.

SFIA also provides guidance where certain levels are not normally seen within a job family. For example, Level 1 and Level 2 are rarely seen with the Information Security skill due to the complexity and skills required. Whereas Levels 6 and 7 are not normally seen for the Incident Management skill but levels 1 to 5 are.

For each skill there are some guidance notes and it explains what you can expect from each level. There is also a useful list of links to related skills. For example, the related skills for project management are listed as:

It is important to note that SFIA lists all aspects of technology that includes business change, data science, learning and education, selling, product management, support as well as core Information Technology skills.

Project and Programme roles that you can expect to see that are covered by SFIA…

The content below is to help you understand in practical terms what you can expect from the key roles you are likely to encounter. You can then use the SFIA material for more detail.

Project Management

The Project Manager is the ‘Quarterback’. They might not score many points but they make all the play. However, in projects the project manager not only drives the project forward but also drives the defensive play as well. They make milestones happen (the ‘points’) and they are on top of the risks and have plans in place to ensure risks are minimised or don’t actually materialise (the ‘defence’)

Even at the lowest SFIA level (level 4), the project manager defines, documents and executes the project. At level 4, the projects are small or even sub-projects and level 6 is reserved for complex projects. Level 7 isn’t usually a project manager role but somebody who sets the governance up for projects within an organisation or who authorises large-scale projects. However, at level 7 you can expect somebody will this level of skill to lead strategic, high impact, high risk projects.

What you can expect from the project manager?

• That the project is delivered to time, to budget and to scope/quality. 

The project manager will often refer to their triangle of timescales, cost and scope. They are seen to only be able to manage these three variables. 

What outputs will the project manager own?

• a plan! This needs to be a series of activities that has start dates, end dates, milestones and named resources.

• highlight reports

• a list of Assumptions; the Risk register; an Issues log and a table of Dependencies. This is often grouped together and referred to as an ARID

• a cost model

Details of Project Management in SFIA can be found here.

Different types of project manager

Good project manages control their three variables intently. They will own the timescale, be meticulous about the scope and be heavily involved in the resourcing to ensure that the project gets done. There is a whole toolkit for managing change that a good project manage won’t hesitate to invoke should something change. 

Good project managers keep the risk register simple and proactively manage the risks.

Exceptional project managers will work with stakeholders to ensure that no change comes as a surprise and provide costed options to the person accountable for the project in advance. The exceptional project manager will work with the sponsor/owner of the project sufficiently far ahead so that options are realistic and credible and avoid decisions being an inevitability.

Blame the project manager if…

• the project is delayed
• the project is over budget
• the project doesn’t deliver the features or benefits

In particular, the project manager is at fault if there are any surprises with the timescales, costs or scope. Ultimately, it is the project sponsor that is accountable but the project manager will be controlling the timescales, budget and scope and managing change.

Projects are remembered for being late, over budget or put something in place that is of poor quality.

If you want the change to be successful, ask the project manger about…

• resourcing
• whether the overall risk score is coming down
• what are the chances of hitting the next milestone

Things to look out for…

• Project managers can be light touch. It is common to have project managers on the project only one, two or three days a week.

Business Analysis (or “Business Situation Analysis”; “Benefits Management’ and “Requirements Definition and management” in SFIA)

A business analyst is used to investigate a particular business situation that might be a problem or opportunity. The skill level involved of the individual is linked to the complexity of the problem and the level of involvement of stakeholders. The SFIA model is quite tight for Business Analysis and only goes from level 3 to 6. 

What outputs will the business analyst own?

• problem statements
• business requirements
• recommendations
• use cases
• user stories
• value chains
• ‘as is’ process maps
• ‘to be’ process maps
• pain points

Business Situation Analysis in SFIA can be found here , Benefits Management can be found here and Requirements definition and management can be found here.

Sometimes the business analyst will be involved in scoping the testing. They can also be involved in writing a business case – especially the benefits section.

“Pure play” business analysts are rare. They have a wide range of techniques and tools to get to the bottom of a problem or to be able to capture the benefits of an opportunity. Most sponsors of projects or programmes expect more outputs from a business analyst, however, most sponsors also significantly underestimate the effort and skills required to determine business requirements for a solution or the skills required to actually measure the impact of a problem.

Different types of business analysts

Good Business Analysts will work hard to ensure that the requirements catalogue is complete and create it in a timely fashion. Good business analysts will avoid ‘analysis paralysis’ and excessive delays. 

An exceptional business analyst will be able to articulate benefits as quantifiable, financial and cashable.

Blame the business analyst if…

• requirements are missing (often not found until User Acceptance Testing and can cause cost over runs because of delays)
• ‘as is’ processes that haven’t been discovered
• recommendations are not implementable

If you want the change to be successful, ask the business analyst about..

• reporting requirements
• integration requirements
• data migration requirements
• how benefits are being measured
• threats to timescales, cost and scope

Things to look out for…

• the term ‘Business analyst’ covers a multitude of skills (3 across SFIA). Good ones are worth their weight in gold and most don’t command a high salary or day rate because they only cover a small set of the skills. Good ones are worth as much as project managers but are often seen as subservient. Try to determine which aspects of business analysis your business analysts are actually covering as it might leave gaps in your expectations.

Programme Management

Projects are common; programmes are rare because they are not understood. In SFIA, Programme management only exists at level 6 and 7 and so levels 4 and 5 at project management have no equivalent.

So what is the difference between projects and programmes? Put simply,..

…a projects delivers a single asset that is a tangible output through a unique and temporary organisation. They have clearly defined scope, start points and end points. Projects can be as short as 3 months and can be up to 2 years..

…a programme delivers benefits and the deliverables maybe unclear at the start and the scope can change as the programme unfolds but ultimately are judged on the benefits (increased revenue; increased customer satisfaction etc). Programmes almost always have multiple projects (the “programme portfolio”) delivering separate assets and programme usually last start at 2 years and can go on for as long as 4 years and upwards

So why is there confusion? There is a lot of overlap in terminology. For example, a project will have a business case that articulates the benefits (“programme speak”). Projects can have multiple work streams which can often be referred to as separate projects that contribute to the overall single asset. For example, a new IT system might have a reporting project; data migration project; integrations project…however, these all come together at the same point in time to create the new asset. This leads to a portfolio of projects (again, “programme speak”)

True programmes are rare. However, ‘big’ projects might be termed as programmes to attract high calibre (“Level 6”) project managers and used to justify higher financial reward. Very few organisations have three levels of banding for project managers (which SFIA supports) but do refer to job descriptions as:

• project managers
• senior project managers
• programme managers

Programme managers have overall accountability for each project

Programme management in SFIA can be found here.

This leaves nowhere to go when there is a genuine programme which is why sometimes the term ‘programme director’ is used to describe the person is actually running a true programme. 

Blame the programme manager if…

• benefits aren’t being realised
• benefits aren’t being tracked as each project is delivered

If you want the change to be successful, ask the programme manager about..

• benefits tracking
• the target operating model
• threats to benefits

Things to look out for…

Programme managers often have project managers to support them. I’ve been a programme manager that had 22 projects in its portfolio and we had 4 project managers that handled 4 projects each at any one time. 

Project Management Office/PMO (or “Portfolio, Programme and Project Support” in SFIA)

A good project manager will set the tools up so that tracking, recording, reporting and exception handling has minimum administration. However, big projects and every programme starts to get too big for an individual to control and they need help. This is where the PMO comes in.

A PMO can either be set-up specifically for a project or programme or can lean on a central PMO within an organisation. 

What outputs will the PMO be responsible for (if there isn’t a PMO then this comes down to the project manager)…

• Reporting packs that include highlight reports, risk updates, milestone schedules
• scheduling workshops
• reducing admin for the project team
• tooling (e.g. timesheets)
• Portfolio, Programme and Project Support in SFIA can be found here.

Different types of PMO:

• Weather station: report status with an accurate short range forecast and somewhat variable long range forecast
• Air traffic control: they don’t fly the planes but do control when a plane (or project) can take off (project start-up) or land (project closedown)
• Resource pool: provide project managers, business analysts, project support staff

Blame the PMO (or project manager if there isn’t a PMO) if…

• reporting packs are late or inconsistent 
• actions are overdue
• risks aren’t being managed
• the project team complain that there is too much admin
• decisions are not being taken on time

If you want the change to be successful, ask the PMO (or project manger if there isn’t a PMO) about..

• benefits tracking
• the target operating model
• threats to benefits

Things to look out for…

• if there isn’t a PMO and the issues highlighted above are starting to materialise then it is time to set-up a PMO. The project manager might not welcome this because it maybe seen that they are failing but if you are the sponsor of the project then you are accountable and need to act
• What type of PMO you actually have. Some will step in without asking if projects are off track, some will identify interventions and make recommendations and the weather stations will just tell you it is going to rain without telling you what to do about it.

Technical Lead (“Solution Architecture” in SFIA)

It is often assumed that the supplier will define what the solution looks like. However, rarely will a solution exist in isolation. Technical solutions, even cloud based products, need to be integrated with other technical products and the technical infrastructure of the organisation- “Solution architecture”. 

In addition, solutions need to be kept simple (using configuration not customisation; “No code/low code not pro-code”) and there needs to be a technical authority to oversee what the supplier is proposing at every turn- again, “solution architecture”.

It is possible that somebody from the organisation’s IT team can be assigned to the project but this person needs the technical understanding of the solution that the supplier is providing as well as an understanding of the technical landscape of the organisation. Very few people have skills in both.

What outputs will the technical lead be responsible for…

• Ultimately, the quality of the technical solution. Think of this as the supplier will deliver a washing machine but the technical lead is responsible for plumbing it in and wiring it up
• …a sustainable solution that the in-house team can manage once the supplier and project team have been disbanded and moved on

Different types of technical lead:

Information Technology covers a broad spectrum and solution architects typically from a specific background and so have a lean towards one of a number of areas

• ‘data’ such as database managers or developers
• ‘hardware’ such as servers and storage
• ‘software’ such as coding and development
• security’ such as information security analysts

Blame the technical lead if…

• The solution doesn’t work
• The users are frustrated with the user experience (e.g. too many clicks)
•  There are data protection/information governance issues that delay implementation

If you want the change to be successful, ask the technical lead about..

• How technical decisions will be made?
• Where is customisation/pro-code unavoidable?
• What are the key technical risks?
• Which other organisations have successfully implemented what we are attempting (if any)

Things to look out for…

• Try to find out what the technical lead’s background is and what they lean towards. For example, a software background might make them particularly skilled in the areas where coding is required (such as integration).
• The organisation may have an Enterprise Architecture function or individual who can provide standards and policies but is unlikely to be able to dedicate the time required in order to be involved in the number of design workshops, attend daily stand-ups and scrutinise the testing.

Hybrid roles

There is a lot of cross over in the project and programme management world. Things to look out for include:

• “PM/BA” (a Project manager and Business Analysis combined). This can be sometimes justified if a light touch project manager is required and the business process is relatively simple and not changing. In this instance you can expect, for example, the Project Manager to create the requirements catalogue
• Technical Project Manager (a project manager combined with a solution architect).
• Project Manager/PMO. This is common on smaller projects where you have an experienced project manager. However, smaller projects with a level 4 project manager are often supported by a central PMO.

This article is for you if you are about to start working on your first Oracle project as a contractor

I’ve been running technology change programmes as a contractor for nearly 20 years. In doing so, I will typically hire 20 contractors onto any given project. Some have been with me on other engagements and some are people who I wish I had known when I first started out.

The people I enjoy working with most of all are those that are contracting for the first time. This can either be students that I’ve taught or people who have worked in a client role who have decided to make the leap to becoming a contractor on an Oracle project.

Tomorrow I’m due to have a call with just such a person- Karen. This isn’t their real name but everything else is. So, if you are about to start on your first project then read on.

I’ve worked alongside Karen on one of my previous clients and she was instrumental on an HCM implementation. Karen was the client lead at the Director level for specifying the Oracle HCM system covering recruitment, Oracle Time and Labour (OTL), Absence and HR admin. During the implementation Karen supported the client Subject Matter Experts and had a key engagement role with the System Integrator. Ultimately, Karen signed-off the User Acceptance Testing and took the project live and through hyper care. Kare over saw the transition to “Business as Usual” and would mange 23 quarterly upgrades. She also managed the transition of the Payroll & Pension team into her command and was responsible, by my count, for 40 monthly payrolls in Oracle cloud. She also managed the implementation of Oracle Help Desk as well as Oracle Learn and ran the Oracle hub of Subject Matter Experts. For four years Karen managed the relationship with the Oracle Managed Service Provider.

At the same time that Karen decided to go contracting,  a “Karen shaped hole” opened up on my project and I jumped at the chance to get Karen onboard.

What to do and not do

This is what I going to tell Karen tomorrow ahead of her starting on Monday. It would be the same advice I would give anybody starting on their first Oracle project.

1. Be clear on what your objective is. The difference between a corporate role and a contractor role is that you won’t get bogged down in the corporate day to day affairs such as appraisals, line management and a whole load of other tasks that you never realised got in the way of doing your job. As a contractor you can be laser focused on your objective. However, you need to be crystal clear as to what your ‘mission’ actually is. I often find that the client is not clear themselves as to what the problem is that you are expected to solve. Write the problem down and reflect back on it often- I’d suggest weekly. Also, in writing down the problem make sure you know what “done” actually looks like. Each week identify the 3 things that will move you closer to your objective. It often helps to create a weekly highlight report that explains what you achieved last week; what the 3 things are you are planning to achieve in the week ahead and any issues that management need to be aware of. Even if there isn’t the stated need for such a highlight report it is worth creating one even just to be accountable to yourself.
2. Keep an eye on your watch and not your calendar. As a contractor, the client will be either directly or indirectly aware of what you cost. In the corporate world, completing a task might have taken two weeks; in contracting this comes down to two days. What was two days is now two hours. Remember, you don’t have all the corporate ‘noise’ to worry about any more. If the task is sizeable then always break it down into bit sized chunks. The delivery of each chunk should be a measurable achievement that totally aligns with your mission. Everything should align with your mission -otherwise you are not working on solving the problem you were hired to fix
3. Get the administrivia out of the way on day 1. No client wants to spend top dollar for somebody at the end of the first week who doesn’t have a security pass or a laptop. You’ll have one day grace to get yourself up and running. No excuses. 
4. Build trust fast. You’ve been brought in to solve a problem; talk about the problem you’ve been brought in to solve- not the job title you’ve been given. Talk about your achievements from elsewhere and not the job titles you’ve had. 
5. Build in time to manage your communications. You are there to do a difficult job and there will be challenges along the way. You will encounter issues as well as your ‘worry beads’ of why you might not be able to complete your mission. These ‘worry beads’ should be seen as risks. Make sure you are logging the risks and issues associated with your objective. If the client has a risk and issue process then use it. If not, create one. I’d recommend at least 20% of your time to be focused on outward communication of how your are progressing; what your risks are and what you are doing to manage them.
6. ‘Imposter syndrome’ is real. High up on your list of worries will be the nervousness you have and possibly the feeling of being a fraud. Firstly, no need to log this worry with the client as a risk(!), however, all the contractors you are surrounded by will have this worry too. My advice is to be reflective. Look back at the experiences that made you successful elsewhere. Find yourself a mentor and dial in with them at least monthly
7. “Talk less, smile more”. The words from Aaron Burr in Hamilton will serve you well. For sure, never go to a meeting and say nothing but do be concise; ask questions to see clarity and dont seek to come away from a meeting with the most actions. In the corporate world you might feel the need to justify your role by having lots of actions to do. However, if it doesn’t help you achieve your mission then it is purely a distraction.
8. Be yourself. Probably, more importantly, don’t try and be somebody you are not. Keep focused on your mission and don’t try and solve the problems that other people are responsible for solving. 

Are you part of an Oracle project to move HR, finance, payroll, procurement or customer experience to the cloud? If so, then this article is for you. The move to the cloud is a big undertaking but what happens after the project is complete? This article will help you understand the role of a Managed Service Provider (“MSP”), what they do and what options you have.

Terminology

I will use the term Enterprise Resource Planning (“EPR”) as a catch-up for all or any of the modules that are moving to the cloud. ERP is a very broad term that usually describes a platform of inter-operable applications and modules to manage (often) some of your organisational resources or (rarely) all of them.

A hot fix is a patch that is applied outside of the quarterly upgrade cycle that is required to resolve a defect in the system

Platform-as-a-Service (“PaaS”) is the place where we build custom configuration extension to deliver a workflow that is not supported in the core ‘out-of-the-box’ product. “PaaS extensions” is the term we use forone or more custom scripts that are considered as a customisation.

Context

The following chart shows the hype curve for ERP from Gartner:

The hype curve shows that there are two areas of extreme maturity for ERP: firstly, the actual managed service itself (The Oracle cloud) and secondly the third party support that is available.

Third party support comes in two flavours: firstly, the system integrator that actually helps you migrate to the cloud and second is the MSP for what happens once you are in the cloud. The differences between a system integrator and a MSP far outweighs the similarities.

Moving on from a System Integrator 

The system integrator helps a client through the software development lifecycle from planning through to deployment. This journey goes through analysis, design, configuration & implementation and testing prior to cutover and go-live. During this journey a series of configuration work books (“CWBs”) will be created which will document every part of the system. The CWBs would allow a third party with the appropriate skills to recreate the entire system from scratch. To this end, the CWBs are both large in number and extremely detailed. The system integrator will handover the CWBs at the end of the project. The CWBs will be the one (and sometimes only) deliverable handed at the end. You may well have spent years and millions of pounds with a system integrator and suddenly all you have to show for it is dozens of CWBs which often are simply Excel workbooks- that and the cloud based system itself. At this point you have an option:

1. Support the system yourself 
2. Handover the support to an MSP

Support the system yourself- “Going it alone”

The first option cannot be ruled out but is highly unlikely. The system integrator will have utilised a large number of functional consultants who are experts in their application (HR, Payroll, tax, finance, procurement, recruitment etc). It’s possible that a consultant supported more than one area (e.g. Time & labour & Payroll) but the likelihood is that there were many consultants. The cloud based applications are so diverse that you won’t simply have one functional consultant who understands the whole system. These consultants did the analysis, design and configuration for their part of the system and, more importantly, understood the impact of their module on other parts of the system. Behind the scenes, the consultants would have been collaborating with each other to ensure that workflows, modules and applications all joined up so that data flowed seamlessly through the ERP system. It would have been a full time job for a lot of these consultants for 12-18 months. Some of the smaller modules (e.g. Taxation) might have required somebody with deep expertise who may have only been part-time. 

Once the project is finished then the system integrator will depart (usually after a short warranty period). From this point forward, your organisation will not start still. There maybe changes to your operating model, changes to prices, tax legislation, you might be new products to market. Changes in your organisaition that will almost always result in changes to the system. In fact, any change to any drop down in the system or the business logic in terms of how the system works. Also the Oracle cloud system is upgraded every three months and this itself might bring new features you want to utilise or create a conflict with how your system was set-up in the first place. It is possible that a quarterly upgrade ‘breaks’ one of your existing key workflows. From experience, I’d recommend planning for a breakage once every five or six quarterly upgrades.

To make any of the changes to the system you are going to need deep functional expertise. This expertise will need to be as deep as those skills that first created the system. Every change needs to be analysed, designed, configured and tested with a full understand of how the system is configured and how the change will impact all of the other parts of the system. To do this safely will require a team of functional consultants as large as the team that originally built it. This might not seem like too much of a problem but the issue is that the volume of change after go-live is likely to be considerably lower than the amount of work required to create the system in the first place. Put simply, you will have a large number of expensive functional consultants sat around for a large amount of time doing nothing. Once in a while you will require one of the functional consultants to spring into life to make a key change. 

It is not to say that “going it alone” is the wrong answer, however, you’ll have to do the maths to determine if the volume of change warrants it. “Highly unlikely” will be the answer.

Handover the support to an MSP

From the above description, a model of ‘fractional functional consultants’ would be a good solution. This is exactly what you get from a MSP. You will have an over-arching support contract with access to consultants with deep functional skills. The MSP will usually front this with a service desk. The MSP business model is that they will be supporting a number of clients at any one time that makes it economical to employ functional consultants for each area. The MSP functional consultants will be available for small, medium and large sized changes and their work is scheduled in on a priority basis. Most MSPs will have more than one functional consultant for each area. This helps with not only from the perspective of resilience but it also allows the MSP to allocate named individuals to specific clients so that they get to know the configuration for that client as well as the client side team.

Services provided by an MSP 

Your MSP will provide two core services often referred to as “Break-fix” or “Service requests”. 

Break-fix incidents

A break-fix is where there is an incident because something is not working properly. Ultimately, these are rare. For example, a customer invoice that is not being picked up by advanced collections but this is probably a ‘bad data’ in the system as a result of a training or process issue somewhere else in the organisation. It is also possible that there has been a technical issue on the Oracle cloud based platform that is resulting in processing issues in your organisation (however this is rare). Another, more common reason, is that a quarterly update has not been tested fully and that a ‘hot fix’ is required. PaaS extensions are particularly prone to issues associated with quarterly updates as Oracle will not have done in-house testing against your PaaS extension. It is often the case that the MSP will raise an Service request with Oracle themselves if the incident is related to the product or the underlying cloud based platform. Your in-house support team will have visibility of the Oracle Service Request and usually the MSP will manage the ticket with Oracle directly on your behalf.

Service Requests
This is by far the high volume of contacts made to the MSP. These can be thought of as “How do I?” questions. It’s often the case that MSPs will provide knowledge base articles that will help you find the answers and this can often be on self-service support platforms such as ServiceNow or Salesforce. Common Service Requests will be responded to by the MSP service desk while less frequent, deeper questions may get referred to the functional consultant. Unlike incidents, it is rare for a client service request to require an Oracle service request to be raised. This is because the MSP is there to support your configuration and Oracle is there to support the core product. “How do I?” Questions mostly occur as a result of a need to understand how the product behaves with the configuration itself. You won’t go far wrong if you remember that “MSP is there to support the configuration; Oracle support the product”.