What’s the best use of an organisations capital? Are you sure? Is the dollar you plan to spend in one, three or fifteen years time the best way to spend that dollar? It might be the best option right now, but what happens if your business environment changes? How do I recognise the change and adjust my capital budget appropriately, both now and also when updating budgets for future years? The usual view of managing a capital budget is, certainly in transactional ERP systems, to ensure that when a dollar gets spent it is spent from an approved bucket of money, and the user notified where a budget is exceeded or is in danger of being exceeded. There is very little integration between why the budget is approved, and what it’s trying to achieve, and the day-to-day transactions against this budget. This can be remedied by integrating the SAP portfolio management solution with the SAP financial system. And maybe including some parts of Investment Management depending on how stringently you need to control the budget.
High level budget process
Coming out of your organisation’s strategy are the objectives that need to be achieved to ensure that your organisation remains competitive. What are the capital requirements needed to achieve these objectives? Capital needs to be allocated to projects that support these objectives. The proposed capital projects will be across a range of areas – building new staff facilities, new production lines to support growth or the introduction of new products. Sometimes organisations drive a top down approach to the allocation of budget to projects. A dollar amount is allocated to each division and local management has to allocate appropriate projects, some organisations build bottom-up budgets where ideas, requirements and initiatives (I’ll call these portfolio items) are collected and consolidated. The proposers of the portfolio items need to justify the capital expense and capital is then awarded based on the financial returns of the proposal, the amount of risk associated with the project and the availability of both internal and external resources to deliver the project. The number of portfolio items to be assessed in each budget round could number into the thousands. With a considerable amount of work done to record and capture this data – if an item is rejected you’d like to keep the information and have it available for the next budgeting round. SAP’s Investment Management (IM) functionality does not do this (bar the information kept on an appropriation request). IM only captures the approved $ value with just about no other information related the capital needed. There is no ability to prioritise items across the portfolio or to manage the items through an implementation methodology. Once approved the budget is relatively static and it’s fairly cumbersome to make changes to the approved budget – especially where you need to make changes in future years.
The approval process involves collating all the requests and the related documentation and submitting this to the capital approval board. If you organisation only approves a few large items then this step of the process is easy, but there are usually many items needing approval. Most organisations will have many items with differing values, from the $20000 plant modifications to $100m or more plant constructions. It’s usually a struggle to manage and track the requests, particularly the smaller ones, through the approval and acceptance process. A tool is needed that can manage and workflow these requests. The SAP PPM solution is able to do this better than investment management. PPM is also able to assess the budget based on non-financial measurements, such as technical and commercial risk, and make this information available with common corporate wide standards, during the approval process. There are some other portfolio management features that could improve the approval process, such as links to related documents and e-mails, multi-hierarchy classification of portfolio items, what-if analysis, multi-project reporting and standard business content for reporting.
An Expected Commercial Value against Assessed Risk bubble diagram in PPM5.0
Organisations usually discuss the monitoring process on two levels. As active transaction based budget availability control or through reporting. By availability control I mean the checking of a budget every time cost is incurred, and then warning the user if the budget is within say 80% of being spent. Indeed some organisations request that when 100% of the budget is spent no further spending is allowed – usually this just causes frustration. Static, project independent rules are also not sensitive to the project being worked on – 10% of a $10000 project is very different to 10% of a $1m project. Accurate, real-time reporting of budgeted against actual spend is often a better way to manage a budget across a project with different values, risks and expected outcomes. This is often the most pragmatic approach for all but a few customers. During the monitoring phase there is also functionality that makes PPM a better choice than IM. PPM allows for the ability to review groups of portfolio items. A review is a standard set of assessment criteria which can be applied to the group of portfolio items on a periodic basis to ensure that the items are rated consistently. Evaluation functionality allows for real time checking of planned vs. actual dates and changing the status of the item to alert the project manager to schedule or cost slippage. Metrics management functionality can be used to asses the impact of your capital spend on the performance of your organisation. Did the plant modification increase throughput, has the organisational change increased efficiency, was the expected commercial value achieved?
I started this blog by questioning whether you should use IM or PPM for a capital budget. I hope I’ve been able to highlight some of the criteria so that you can make a better decision. You should use IM when there is little need to keep any details of the budgeted items in SAP and when there is a need for real-time active funds availability. PPM delivers more functionality and should be used if you need insight into what has been budgeted, you need to capture financial and risk information against the items and you need to track and review these items continually .
This blog will, in 1000 words or so, attempt to explain how the alliance contracting model can be supported by SAP. A brief history and explanation of alliancing will be followed by a description of an SAP ERP solution to support the transactional and reporting requirements of a Non-Owning Party (NOP) in an alliance contract. The solution will support the ability of the NOP to do easy auditing of claimed costs, accounting for all transactions during the alliance contract and report on all categories of cost, mark-up, revenue and risk.
The alliancing concept has been used in Australia for more than a decade. The Alliance contracting model is selected to reduce project costs and delivery timelines. The contract is constructed to encourage collaboration between the Owner and the various NOP’s responsible for delivering the project. The claimed benefits realised during an alliance contract are an increase in the value for money gained by the Owner Party (OP). Two key features of an alliance contract are: firstly defining and recording which costs are recovered from the OP and, secondly the performance criterion which needs to be met for the NOP to access project profits. These features are best represented by a diagram from the Victorian Dep. of Finance and Treasury’s Complete Project Alliance Guide document.
As can be seen in the diagram above, there are a number of costs that have to be recoded in this model: Total Outrun Costs (TOC), the costs that make up Limb 1, Limb 2 and Limb 3 and the question is then: how are these easily tracked in SAP to ensure that your business maintains profitability during the alliance. The SAP functionality that I propose you use for this is discussed below:
On a transactional basis the ‘incoming costs’ which need to be recorded on the project will be from payroll, overhead (usually via a cost centre and will include management and other corporate overhead), project specific expenses and the cost of sub-contractors; other cost types can be added if needed for specific contracting agreements. These costs will flow through the project, which is registered in SAP, and then billed to the customer.
Allocation of actual payroll costs to the project: Allocation of actual costs to project after period end and after all award interpretation has been done is performed directly from the payroll run. These costs will include overtime and other variable costs.
Ability to record different cost types on the project: Configuration so that all cost categories are recorded automatically on the project and differentiated based on the cost type (the cost element in SAP). The cost type will not be determined by the user but is determined by the transaction being executed. When payroll runs the costs will post to the project against the correct cost element without user intervention, the same applies to goods receipts, timesheets, etc. So just by doing the transactions correctly the integrity of project costing and alliance reporting is maintained.
Billing the OP the correct costs: Since all costs are allocated to the correct projects against the correct cost element (cost category) SAP has all the information needed to determine whether to bill these costs or not. For example payroll costs and management overheads are on different cost elements so when I do the billing run SAP will bill the payroll costs (since they are not at risk), SAP will check whether or not the limb2 pain/gain KPA have been met and bill the overheads and/or normal profits depending on the alliance contract agreement. At time of billing SAP will check the NOP’s entitlement to limb3 profit and bill this if necessary.
Accounting for ‘at risk’ profit: Until the project is completed there is usually a portion of the profit that is ‘at risk’ and which may need to be paid back to the OP. SAP’s Results Analysis (RA) functionality is used to post ‘at risk’ profit to an accrual account, which is released to profit once all KPA have been signed of.
It’s my view that SAP is able to give an easy-to-use, accurate and integrated solution to supporting alliance contracts. Implementing the functionality described above will enable the NOP to keep real time track of all costs on the project and continually assess the costs against the contracted alliance agreement. All costs are recorded and can be reported on after the project is complete and can be used to improve the determination of total outrun costs for future projects. The reporting is also useful to define the fee percentage on future projects.
Good reference documents are Philip Greenham from Minter Elison’s Alliancing: A glimpse of the real world view, 2007 (http://www.xyz.au.com/members/intelligence/pdf_files/Allianci_Paper.pdf ) and the documents on the Victorian Dept. of Treasury and Finance website (http://www.dtf.vic.gov.au/CA25713E0002EF43/pages/project-alliancing)
I sent a colleague of mine this link recently in connection with a discussion we were having on project budgeting.
It’s very difficult to pick a start point in this ‘Mandelbrot’- and it’s sometimes like that for project budgeting. If you are an SAP customer it’s important to have a ‘start point’ in the process as this will help you decide which of the tools delivered by SAP will best meet your requirements.
Let’s look at internal projects (customer projects have a revenue leg which just confuses the discussion at this stage – the principle is the same) – maybe R&D projects or six-sigma projects would be good examples. There are two main areas I’ll talk about in this blog, firstly the planning of the project and secondly the execution of the project. There are some critical questions to ask concerning both of these areas, the answers to which will help you get to a stating point in designing a robust cost planning and tracking process.
Does the organisation do top-down or bottom-up planning? Do you plan your costs at the WBS level, and distribute a lump sum across the duration of the WBS (top-down) or do you plan down to hours and dollars per day, and then roll this up to the WBS level (bottom-up)? There is no reason an organisation can’t do both. Or indeed plan at different levels in a single project. For example you may allocate a lump sum to the ‘Planning ‘stage of a project, while doing cost planning at a lower level for the execution phase. It is not an either or choice but you have to be able to give your project managers clear guidance on the options and which to use in which case. This guidance is not meant to be restrictive but to ensure that subsequent processing of the project is as smooth as possible. As an example we could say that all WBS elements that the Project Manager expects to be less than $50k don’t need detailed planning. Another guidance statement could be: All projects with a start date less than a year into the future need detail planning. This allows Project Manager and budget seekers to get budget allocated but not have to do the detailed planning.
So what happens on execution of the project? The level of planning chosen initially determines what can be reported on during the execution of the project. If your planning is done at a high level, on WBS elements, as a lump sum, then the progress of the WBS element can only be done by time or total costs. You’d not be able to use effort as a determinant of percentage of completion (POC). If lower level planning is done on the project then effort, as the number of hours expected to be done and then compared to the actual hours can be used to determine percentage of completion. During the execution of the project it is often a requirement to be able to check budget availability during the project. The decision here, when using SAP tools (RPM or Investment Management), is whether or not you need ‘real-time’ checking of funds available, or whether reporting on planned costs against actual costs is a sufficient control. Many organisations, initially at least, select real-time budget control, i.e. a transaction (purchase order, time confirmation, etc) is stopped if funds are not available. While this might seem appealing initially, what does the organisation do when this happens? Stop the project? Usually not (although there may be cases where you want this to happen) so reporting, perhaps with an e-mail sent if a budget is exceeded is a often a more pragmatic solution.
As you look at your SAP supported project cost planning processes a good starting point is to decide when you do top-down and when you do bottom-up cost planning and, once planned and started, how you control the actual costs flowing against the project. These decisions will be a good framework on which to build better project cost management processes.
I went past my local bicycle shop last week (I needed a new seat post and got a fine aluminium one) and saw this work scheduling solution on the wall. It got me thinking that some of the concepts that we work with in enterprise wide workforce management solution are being addressed in the St Kilda Cycles workshop (the St Kilda Cycles Solution – SKCS) – and also that a clear view of the business requirements is critical in determining the right solution to workforce scheduling problems.
It’s become a bit of a bug-bear of mine over the last year – and I’m sure to blog about this in the future so here are some terms of reference. I’ve been in far too many meetings and workshops where there is an amazing amount of confusion on the basics of work planning and scheduling. The meetings I’m in are usually at a fairly high level and people from across the organisation get invited, everyone attending understands what their role is in the planning and scheduling of work but as soon as the teams are combined to discuss an enterprise wide view of this it all collapses into a debate on terminology and misunderstood timeframes. In this blog on maintenance planning and scheduling I’ll talk about one of the most important aspect of this: TIMEFRAMES.
- The long-term is far enough into the future to be able to change any of the factors which could cause a constraint when we get there. For maintenance planning this could mean increasing the number of people you employ, changing the types of machinery you use, outsourcing some of your maintenance, preparing for corporate strategic objectives or legislated requirements or any other of a number of factors which usually have a long lead time. Generally this is more than two years into the future and in the case of public sector (electricity generation, infrastructure, dams and roads can go out to 30 years). A company would usually use Strategy Management or Project and Portfolio Management tools to manage long-term maintenance, shutdown and project requirements.
- Medium term – this is little self-defining: the medium term is between the long and short-term! That said there are some features to look for in deciding whether or not you are planning for the medium term. You’ll ask questions like: is this within the current budget cycle? If yes then you are probably in the medium term. Are you able to change any of the constraints? If you can change only some of them then probably in the medium term. As an example, in the medium term you probably couldn’t change the size of your workforce, you wouldn’t be able to change the equipment you’re working on but you would be able to change the planned dates and probably also change any dependant activities to optimise the plan around other constraints. The medium term is usually between a month or 2 and a year or two into the future. Any maintenance reliability initiatives would be executed with a medium-term view and the results fed into the short-term plans. Project managers would develop detailed planning on projects that have been approved in the long-term plan. Detailed planning for shutdowns will also be performed. Maintenance budgets would be created based on historical or zer0-based budgeting principles and work orders will be generated to support this budget.
- Short term – In the short-term most, if not all, of the constraints are fixed. Your work force is fixed (although you may have a sub-contractor workforce which could take up any slack). The dates and dependant activities are fixed. The spare parts and special tool requirements are fixed, in the short-term it’s probably too late to order longer lead time spares or book job specific tools. The short-term looks at anything from a day or two to a month or two into the future. Where we’re doing work on ‘fleet’ type of assets we should, at this stage, known the exact day the machine (Backhoe Loader, Train or even Bicycle!) will be coming into the workshop. All materials and spare parts needed to execute the work orders and projects would have been ordered, or at least the requirement with a delivery date would have been defined so that the Material Requirements Planning can pick these requirements and create purchase orders for the materials. Sub-contractors would have been advised of the work requirements. Work will be allocated to specific people and qualifications will be checked. The “St Kilda Cycles Solution (SKCS)” covers the short term – the workshop manager has created ‘work orders’ – he know what needs to be done, he can order in parts and make sure that not too many bike mechanics are needed on a Monday! Sure it’s not a high tech bit of scheduling and optimising software but at the cost of a piece of board and a few pegs it probably works just fine.
- Immediate – this is an important category in maintenance planning and scheduling, this is where the scheduler responds to what is happening here and now. It’s at this stage that the planning (or lack of it) has been done. It’s how the scheduler responds to events as they happen; it’s entirely reactive with the scheduler only able to respond to events as best she can. To be able to respond to these events as effectively as possible the scheduler needs access to real-time information such as who is the closest alternate technician, which warehouse has the part available, are other jobs are going to slip because of unplanned events and which jobs can we let slip and which ones do we absolutely have to get done? Immediate is from now to a few days into the future. The value in a software solution covering this timeframe is the ability to see demand coming in from the short-term time frame and also in being able to track all the constraints (the things we can’t change at this stage) and optimise the allocation of demand to resources based on these constraints.
As you build up an enterprise view of your maintenance planning and scheduling process it’s important to contextualise the discussions you’re having – and allocating the activities within a process to one of the timeframes above is a good way to do this. A good solution will be able to track the initial requirement, through each of these timeframes, as it gets approved, executed and completed.
Don’t you just hate it when you have the wrong tool for the job? We’ve all had to “apply the hammer” to situations which would probably have been better off with a screwdriver – or in some cases we’ve had to apply pliers to nuts!
Sometimes you just have to do what you have to do – but is it good enough as a long-term solution to a job you need to do everyday? Well, you probably wouldn’t put up with it. So why, all too often, do we put up with using the wrong “tools” when working on our business systems. Here are some examples of the wrong “tools” used in business systems: asking trades people to log into the corporate system to update work orders or time confirmations, asking managers to log-in to complex reporting tools to understand their businesses performance or having to deliver reams of dated, static paper reports to executives. All of these are examples of people using the best that was available years (or in some cases decades) ago to get their job done. And the efficiency of the organisation and our own performance suffers – it is notoriously difficult to get accurate and timely information on asset performance back from maintenance technicians, managers still complain about not being able to get information ‘out’ of a system and executives often need to make decisions based on information that is at least a month old.
Over the last few years (I’ve still got a beach towel from the 2001 ASUG Conference Usability Lab – although that probably says more about my ability to throw things away than anything related to system usability) there has been a lot of work done on improving the usability of ERP systems – particularly how screens are designed, which fields are placed where and how many ‘clicks’ it takes to complete a transactions. This is still important but the game has changed – it’s no longer necessary to have a “computer” to transact in an ERP system. Ignoring machine-to-machine transactions – integrating to SCADA, RFID, etc – and looking only at human data entry we can find mobile device, digital pens, faxed data with ORC which are just some of the ways people can transact and support business processes. Service Oriented Architecture and Business Process Management has also made it easier to trigger business system transactions from interfaces other than those delivered directly from the ERP software vendor or by technology other than the ol’ PC.
The starting point in making decisions on which technology to use are the organisations ‘to-be’ business processes. All business re-engineering, ERP implementation projects, improvement projects etc would have as output the business process and which systems these process will be executed in and also probably a ‘swim-lane’ definition of the roles needed to execute the transactions. The nature of the transaction is not always defined. What do I mean by that? I mean that there are characteristics of a transaction that lends itself to different technologies. These characteristics are: complexity of transaction, frequency of transaction (number of transactions per day, week, etc) and % of total users doing the transaction. Lets look at an example, an activity in a process might be ‘Enter work order time confirmation’. How complex is this transaction – not very it’s just entering the work order number, the operation and date(s) and start and end time. How often are these transactions performed – very often, a large organisation would have hundreds of these coming in every day. What % of system users are doing this – probably a high percentage. This sort of transaction: low complexity, high volume and many users needs the simplest of interfaces. Something like the digital pen or an ORC paper reader would be ideal. What other transactions fall into this category? Probably things like project cost forecasting, work order status update, goods receipt and proof of delivery. And so as transaction become more complex and maybe less frequent the more it makes sense to use the native ERP interface. Of course all transactions will always be available at least in the core ERP user interface. I’ve put some technologies in a continuum below technologies which could applied to different business transactions, with low volume, high complexity on the left and high volume, low complexity on the right.
My main point from this post is that a single user interface will probably not drive business efficiency and process compliance and a range technologies should be assessed to get the best UI. How do we know which is the best UI, what’s cost benefit analysis for any of these technologies. Well I’ve got some ideas which I’ll post next time.
I’ve recently been doing some work on linear assets and the functionality an Enterprise Asset Management (EAM) system needs to support the management of linear assets. Sure we need the basics – we need to be able to ‘reflect’ the technical object structure in the computer system and we need to be able to plan and execute work against the technical objects and we need to be able to record information (failure codes, costs, measurements, inspections etc) against the technical objects. But there’s more, once we get to a lower level of detail, once we start defining the asset structure and the information that needs to be recorded it becomes apparent why this:
Is different to this:
Linear assets are prevalent in many industries from railways to roads, pipelines to electricity distribution networks and canals and waterways. I’ve identified five areas that need to be assesed when selecting and implementing a linear asset management solution.
1. Structuring. Long and straight is different to up and down. There is always much discussion during any EAM implementation on how to structure the organisation’s technical objects and this is usually related to the level of detail needed to support the operational and reporting requirements. It’s no different when we structure linear assets and we need to answer the two questions – what level of detail do we need to capture maintenance history and costs? And what is the organisations capacity to support this level of detail?
2. Linear is not GIS – linear asset management pre-dates Geographic Information Systems and they are not the same thing. The two concepts complement each other, GIS does not replace LAM. Linear assets can have geo-coordinates and can be represented as a line or points on a map but most organisations maintaining linear assets still use non-map based linear representations to manage their assets and plan and record work on those assets. The one area where there is good synergy between the information collected by a LAM solution and GIS is in the area of reporting. Information extracted from a LAM system to a information warehouse is a good starting point to overlay linear information onto a map and run reports which answer questions such as which section of road has the highest number of potholes, etc.
3. Dynamic segmentation is the ability to defined changing characteristic features along the length of an asset. For example a segment of rail track will have changing features along its length. A segment of rail might be anything from 5km to 100km long and through this length the features such as rail type, sleeper type, fastenings, alignment etc will change. These features are not assets, the rail track is the asset and the features can change across that asset in a dynamic way as the segment of track is maintained.
4. Liner reference methods. The position on a linear asset (relative to the start point of the asset) could be represented in a number of ways. The position could be an absolute point as measured from the start of the segment, or it could be a measurement relative to some defined marker such as a kilometer or mile post. Or indeed it could be the distance from a well known marker, for example 5oom from the large oak tree. A good LAM system will be able to translate absolute distance into relative distance. This translation is usually needed when someone in the field reports a fault on a linear asset as a certain distance before or after a marker. When a work request is created only this distance is known and the LAM system then convert it to absolute distance against the asset.
The diagram below from Paul Scarponcini shows some of the methods used to record distance on a linear asset.
5. Mass changes. Enterprise Asset Management is always static, or master data, intensive. LAM is no different. Tools are need to effect mass changes to the linear assets under management – this is particularly relevant where costing boundaries change and both the linear assets and point assets need to be updated with new cost collectors.
There are many more ways that linear is different from point – these are the most important you need to consider when selecting and implimenting an enterprise wide linear asset managment solution.