Archive for the ‘Supply Chain Management’ Category

The high cost of misalignment between MRO Supply Chain and Maintenance Strategies

December 4, 2013

The misalignment of MRO Supply Chain and Maintenance Strategies can result in increased operational, safety, and compliance risk and significantly impact production and profitability in asset intensive industries.

 A solid asset data foundation and an effective Asset Data Governance process as part of an overall Asset Lifecycle Information Management Strategy can help to minimise these risks, improve asset availability and increase profitability.

 Competing Interests And Misaligned Strategies

 Hundreds of millions of dollars are spent annually in asset intensive organisations performing projects to optimise maintenance and reliability strategies. Designed to improve asset reliability and performance, these projects typically result in a set of recommendations that outline the specific maintenance activities that should be performed, the recommended frequency of performance, and strategies to monitor performance for ongoing continuous improvement. These studies are normally commissioned by operations and maintenance stakeholders responsible for production and asset availability.

Separately, companies spend billions of dollars each year performing studies focused on optimisation of their internal supply chains. These projects are commonly sponsored by executives responsible for finance and supply chain; very different stakeholders than those who commission the maintenance optimisation projects.

The MRO supply chain materials (spare parts) critical to the execution of maintenance strategies are commonly lumped in under the umbrella of the corporate supply chain optimisation initiatives.The business drivers behind maintenance strategy optimisation projects and supply chain optimisation projects are frequently disconnected and sometimes directly in conflict. This misalignment creates problems in a number of areas. First, maintenance strategy optimisation projects sometimes recommend an increase in spares inventory; not less. Secondly, inventory reduction recommendations driven from supply chain optimisation projects mostly fail to consider the impact such changes will have on asset reliability and performance.

Companies who have not established strong alignment between maintenance and MRO supply chain strategies are poorly equipped to measure the impact such changes will have on cost and asset performance and thus have great difficulty making decisions that will balance these tradeoffs in the best interest of overall corporate performance.

Organisations who have been able to establish and maintain strong linkages between maintenance strategy and MRO supply chain strategy, including effective decision support systems and processes, are much better positioned to make decisions in the best interest of overall corporate performance; rather than only supporting one or another siloed initiatives.

 A Data Driven Approach To Achieve Strategy Alignment

There are many best in class technology products and best in class processes for performing maintenance strategy optimisation available in the market. None of them are of much use without good data.Therefore, one of the first and most obvious gaps that must be addressed before trying to establish strategy alignment is data; master data. It is common (in a Brownfield environment) to discover that greater than 30% of maintainable equipment is not recorded in a CMMS tool. It is also quite common to find more than 20% of unique equipment records in a CMMS are no longer in service.

The first step in establishing alignment between maintenance and supply chain strategies is to know what is actually being maintained, or should be maintained. Performing a maintenance optimisation process on the 20% of equipment no longer in use is hardly a productive use of anyone’s time and money. This first step must include an audit to establish an asset registry that everyone trusts. The safety and compliance risks associated with an inaccurate or incomplete asset registry are huge.

The next step is to ensure that all systems of record for asset data have a common and agreed upon definition of asset criticality. The majority of maintenance strategy optimisation projects will help define and assign criticality to equipment. It is very important to ensure that this criticality finds its way to the CMMS system and is an agreed upon standard. For example; Critical – High impact from failure; Not Critical – Low impact from failure.

This is the first opportunity to align strategies by aligning goals. If an asset is defined as critical and it fails, corporate performance is impacted and everyone should care.

Next, you need to look at all critical items and identify which have Bills of Material (BOM’s).

It is common to find only 30% to 50% of critical assets have complete and accurate BOM’s. There is a BIG difference between having a BOM and having a “Complete and Accurate” BOM. A complete and Accurate BOM is one which is fully aligned with, and supports the maintenance strategy. And don’t forget that the same equipment in different operating contexts do not always have the same BOM.

Equipment BOM’s and Maintenance BOM’s should be considered as part of this scope of evaluation.

The final step in this process is a review of materials associated with critical equipment BOM’s and ensure that the material records are valid and the materials in the warehouse match the materials referenced in the information system.

Advertisements

Risks to Avoid or Manage before they become issues on Business Systems Implementations (SAP Specific)

November 28, 2013

Specifically, the SAP system has been implemented successfully in at least 50000 customers globally. The Majority of project failures are not related to the product or software but tied to the project execution, the software implementation partner or just the people themselves.

This brief will help you maximize your chances of a successful SAP implementation and you are more than welcome to discuss with me any specific questions you may have about managing risks on your SAP project.

Risks and issues are part of any and every major Business transformation project. Put in perspective of large business transformation projects which involve the larger ERP’s (SAP and Oracle) but not limited to, these risks and issues can be huge which could destroy the entire project if not managed and mitigated in a timely manner. Most of these risks and issues discussed here are applicable to any Business System implementation project. However, this brief is based on my several years of experience in leading, overseeing and participating in large ERP projects and also based on some of the projects that have not gone all the way to plan.

Most Common Risks on SAP Projects
These risks listed below are the ones that occur very frequently on a challenged or failed SAP project. There will be no reference to any specific project, but once you read through the risks you will probably be able to guess who and where the project may have been. The ERP Project world has become such a small place that everybody knows every bodies business.

Risk #1: SAP System not producing correct output or not working properly during UAT or post go-live
During UAT or post go-live, your organization realizes that SAP system is working correctly for certain business scenarios but produced inaccurate results for business scenarios with few deviations. You may also see unexpected behaviour of the system such as inability to execute end-to-end business process or cause systems short dump. This risk is common on SAP projects where business requirements have not been captured in detail or poor quality system design during realization phase or the business does not really understand their own process. Ideally this may also mean inadequate testing of your business scenarios.

Risk #1 Mitigation
 Ensure that business requirements gathered during blueprint phase are at sufficient level of detail that clearly describes your business process with examples. Verify that all business requirements are reviewed by the subject matter experts (SME) and approved by the business lead and/or business process owner.
 Ensure end-to-end business process in clearly documented in BPRD documents and process flows covering the most common business scenario as well as all the process variants. Verify that each BPRD document is reviewed and accepted by the SME(s).
 Validate that proper SAP software fit-gap analysis is performed on each and every business requirement. Each business requirement that is classified as “fit” should have corresponding SAP standard functionality covering the requirement or “gap” should have a RICEF object that needs to be developed to address the gap in the SAP standard functionality. This will mean that you have 100% coverage of business requirements with either a standard SAP solution or a RICEF object.
 Integration and User Acceptance Testing (UAT) should be very thorough to cover all end-to-end business processes. Each test case should be driven based on business requirements and business process. In other words, each business requirement should be tested with at least one test case. Most projects have test cases that only test most common business scenarios which can lead to system malfunction when there are variations in business process inputs or process step. It is very important that the test cases cover most common business scenarios and all its variations that represent your day to day business operations.
 Every SAP project should have a high quality requirements traceability matrix (RTM) that will ensure that your RICEFW functional designs and technical designs trace back to meet all business requirements associated with a specific software gap. RTM will also assure the business that each business requirements has a SAP standard solution, RICEF and further on a test case to test each of these requirements.

Risk #2: Project experiencing frequent delays in deliverable completions and slippage of deadlines by the Systems Integrator (SI)
Is your project experiencing severe delays with deliverables taking longer than expected? Are project deliverables submitted as complete not being truly finished and lacking detail?” One common risk on SAP implementations is that your Systems Integrator (SI) may take longer than anticipated to complete project activities and deliverables there by missing your project deadlines. If this happens, it can delay your project phase completion and also result in cost overruns. I have noticed that this risk mostly occurs when the project work effort is incorrectly estimated or SAP skilled resources from your systems integrator are inadequate and does not possess required solution expertise or experience. From programme governance perspective, this risk can be accurately monitored by having a good project plan with well-defined work breakdown structure that will provide visibility into key activities associated with production of essential project deliverables.

Risk #2 Mitigation
 First and foremost, I would recommend that your SAP project leadership and PMO should have a clear visibility to the progress of every key activity and deliverable completion on the project. In order to achieve this, it is important to have a project plan with a good work breakdown structure. This project plan should also be adequately resource levelled to ensure that SAP skilled, SME and project architects are not over resourced

Example: Blueprint phase work breakdown structure for a sample business process ABC may look like the following:
ABC Business Process

a). Requirement Gathering work sessions (AS-IS including a SWOT Analysis)
b). To-Be level 2 and level 3 business process design and Workshops
c). ABC BPRD (Business Process Requirements & Design Document), sign off to commence
d). Fit Gap Analysis
e). High level SAP Solution
f). BPRD and Requirement Review and Approval by the Business Stakeholders

PMO and program managers should review the weekly progress and identify any work streams that are facing delays and likely to be a bottleneck to overall project progress. Attempt to resolve the delays by hopefully increasing participation of SME or project architects. It may also be helpful if any outstanding unresolved items can be de-prioritized if these are not critical to business operations.
 Projects may also have SAP skilled consultants that lack required experience with a specific SAP module that is being implemented. In both these situations SAP customer leadership is unable to identify these kinds of issues because the leadership assumes that your SAP systems integrator is bringing the best SAP consultants to the project. To mitigate this risk, it is extremely important that your project leadership with the help of your SAP project advisor (third party SAP project leadership expert) interviews all systems integrator resources especially the business leads, solution architects, SAP consultants and team leads provided by SI.
 Most often the delays in SAP implementations are caused by under allocation of SAP skilled resources on the project. Ensure that your project has well balanced teams of SME (subject matter experts) from your business and SAP solution experts. Try to keep the resources from your SI like business analysts or systems integration analysts to minimum that do not have any prior SAP implementation experience. You are better off investing this money to have additional SAP skilled resources on project work streams to produce deliverables quicker.

Risk #3: Ineffective use of standard delivered SAP functionality due to lack to knowledge within consulting organizations

Predominately all SAP modules and industry solutions are proven to meet 60-90% of business requirements within a specific industry. This percentage of standard SAP package fit is higher with products that have gone through multiple release cycles compared to those that are just launched. There have been projects where systems integrators lack in-depth expertise of the modules that are being implemented. This results in poor quality SAP software fit gap analysis during blueprint there by resulting in higher RICEFW objects especially with enhancements. A few large enhancements can easily transform into custom development projects thereby blowing the project budget off the roof. I strongly recommend having a project solution architect with in-depth module knowledge or having a senior expert consultant from SAP or your local division of SAP to assure that your project is leveraging maximum standard delivered functionality.

Risk #3 Mitigation
The best way to mitigate this risk is to have representation of at least one senior consultant with product expertise from SAP. As a Project Manager I usually recommend this on most projects that are implementing a new industry solution of SAP. If the project does not allow extra budget for this resource, then one thing every SAP customer should do is to review the fit gap analysis output with SAP and solicit their feedback. This will help your project eliminate RICEFW objects where SAP might have standard alternative solutions.

Risk #4: Lack of business subject matter experts causing project delays
Business team members from the company implementing SAP play a very crucial role on the project. Each major business process or operational area should be represented by at least one subject matter expert who understands how the end-to-end business process is handled today and also how this process needs to work in the future. Inadequate business SME can directly impact quality and progress of requirements gathering, review and approval of to-be business process designs and verification of project deliverables. It is very important to ensure that your business provides required number of SMEs without jeopardizing you current daily production operations.

Risk #4 Mitigation
 In project planning or blueprint phase, meet with business stakeholders to ensure that each business process or operational area is represented with experienced SME. If required numbers of resources are not available, then it may be wise to split the project into multiple releases.
 Do not supplement your business SME needs with business analysts from your SAP systems integrator. Only your SMEs and business process owners understand business requirements. It may not be effective for an external consultant to fulfil this role without understanding your internal business operations.

Risk #5: Lack of confidence of business team in understanding and acceptance of blueprint and overall solution in SAP system
To me this is one risk that every executive and project sponsor of a SAP project should pay close attention. The ultimate goal of any SAP implementation is to transform current business operations into the new SAP system. It is very important that business subject matter experts, analysts and process owners understand the future state business requirements, new to-be business process flows, solution design in SAP and functional documents. If the business team is not onboard with requirements that are gathered during blueprint and solution design in SAP then your project is running a very high risk of business operations not working as anticipated upon go-live. I recommend that every SAP project leadership especially the executive project sponsor and overall project business lead to verify that business requirements, blueprint documents (process flows, BPRD documents, solution design and solution architecture) is reviewed and approved by SMEs, process owners and the business lead. This will ensure a high quality blueprint and realization of blueprint in design & build phase. Ultimately I also suggest that test cases cover all of your business processes and its variations.

Risk #5 Mitigation
 Key business team members especially SMEs should be part of business requirements gathering work sessions. SME should have clear understanding of to-be detailed business requirements, business process design and solution design in SAP.
 SMEs should review and approve each business requirement associated with their business process.
 SME and business process owners should review and approve process flows, business process requirements and design document (BPRD) and high level solution design created during the blueprint phase
 Client Solution Architect (not from your SI) should review, validate and approve the SAP software fit gap analysis and overall solution architecture. This task can be accomplished together by Client Solution Architect and your leadership QA advisor if you have one on the project.
 DO NOT approve any blueprint document or deliverable which is not 100% complete. Do not let your systems integrator invent the definition of “Complete” in order to meet project deadlines. Complete means the document is fully finished and needs no re-work unless there is a change request.
 Business team and stakeholders should have a full buy-in of the solution that is being designed and developed. All the steps above will ensure that you are heading towards a successful path rather than a mysterious avenue of uncertainties during realization and go-live.

Risk #6: Ineffective, rigid and political project leadership
On a very large undertaking like an SAP implementation, the project leadership plays a crucial role in the success of your project. It is not uncommon to see corporate executives (level of vice presidents and senior directors) in the project leadership who are slow decision makers, enforcing cumbersome decision making process when not needed and creating unnecessary political environment thereby causing bottlenecks and impeding project progress. I treat an SAP transformation initiative as a fast moving train and every project leader should adjust and cope with the pace of this train rather than slowing it. What I precisely mean is that lot of decision on an SAP project need to be made very quickly and issues should be resolved in an expedited manner. This will help tasks and deliverables on critical path completed in a timely manner without affecting dependent activities. I use this train example very often and suggest that every leader in a SAP project should be flexible, adaptive and work collaboratively with project leadership to meet one common goal of the project i.e. “Successful on-time and on-budget go live”. -individual decision making authority -always have leadership backup to expedite decision making -leadership and steering committee escalations if bottlenecks are causing project delays. Engage an independent leadership QA advisor to monitor resolve and escalate these issues without any influence of project or corporate environment

Risk #6 Mitigation
 Select project leadership (executive sponsor, business lead, IT lead, change/training lead and project management lead) from your internal organization that have proven track record of successful IT transformation implementation. Make sure these executives are flexible, capable of handling complex project challenges and able to make decision without causing bottlenecks on the project.
 One ineffective and political leader can bring the whole project down. Make sure that you have leaders that are excellent team workers and not the ones that are eager to demonstrate power and authority.
 Decision making on a SAP project (whether a business decision, deliverable approval or issue resolution) should not be solely in the hands of one leader. Depending on the work load, a project leader may have backlog of several key project decisions that need to be made which can ultimately become show stopper on the whole project. Project leadership decision makers should have backup individuals who can evaluate situations and make decisions in scenarios where primary decision maker is not available or lacks bandwidth.
 Critical project risks and issues should be proactively escalated to the project sponsor and the steering committee. Steering committee should also be presented with analysis, alternatives and possible solutions to risks and issues that are escalated.
 Communication is the key between the project leadership and it is important that there is full transparency about project key decisions, risks, issues and status between these leaders. On large SAP projects, I recommend that project leadership should meet at least once every week.
 Project Leadership should keep a “Anonymous Project Feedback & Suggestion Box” for project team members to provide project feedback, express concerns, raise potential problems and suggest avenues of improvement. This will ensure that major unforeseen project issues and challenges are reviewed and addressed in a timely manner. This gives every project team member irrespective of their role and title to voice their concerns or suggest improvements on the project.

Risk #7: Offshoring SAP design and build effort: Is it cost saving or risk doubling? Tighter control on resource skills, work quality and on-time delivery capability
Offshore development centres of big 5 and other SAP systems integrators have proven to be cost effective option to lower the cost of overall SAP implementation. The same SAP skilled resources that cost between $200-300 per hour onsite in the US can be available offshore in countries such as India, Philippines, Europe, etc for $30-70 per hour. This is a no brainer cost saving initiative for any SAP project. But off shoring your SAP project work comes with its own set of risks and challenges that clients in the US are not aware or often hidden due to lack of visibility thousands of miles away. Some of the major risks with offshore development centres are the following:
 Under-qualified resources in design and build teams
 Major discrepancies between actual deliverable progress versus the one reported in weekly project leadership meetings
 Lack of key senior SAP functional and technical key members on the offshore team which leads to critical solution quality risk.
 Language and cultural barriers leading to project work ethics being compromised which can lead major project delivery issues to go unreported and escalated till the very last minute
 Incorrect project progress reporting by offshore leadership to alleviate concerns and anxiety of project leadership.
 “Lost in translation” often business requirements are missed or misinterpreted and similarly functional designs and so on.
SAP customers such as your company does not have visibility and leadership control on what happens in the offshore development centre for your project. We realized this as a huge risk on many SAP implementations. Recently our company launched a new practice of “Offshore SAP QA & Advisory Leadership” which allows one of our experienced SAP senior executive to be your exclusive independent QA representative and work onsite at the project offshore delivery centre. This is not the focus here so if you need more information then you can reach our company.

Risk #7 Mitigation
The best way to make sure your project offshore team is transparent, effective and well qualified to deliver your project on time is to engage a third party SAP project QA advisor (one of our offering) that will allow a senior SAP industry leader to serve as your exclusive representative at the offshore location closely working with the offshore leadership, entire offshore project team and collaborating with your internal US project leadership. Remember that this resource does not work for your SAP systems integrator but for the SAP customer leadership. An Offshore SAP QA Project Advisor will mitigate all the risks mentioned above by doing the following:
 Interview and select each offshore project leader and team member by conducting project management, SAP functional and technical interviews.
 Ensure balanced SAP design and build teams with adequate number of architects, senior designers, developers with some room for junior SAP resources.
 Review project and deliverables progress with offshore SAP project manager and also conducting independent verification of these project deliverables.
 Ensure end to end SAP solution integration with collaboration between project teams across various work streams.
 Independently report project progress to project sponsor and leadership. Also proactively report offshore project risks, issues and recommend areas of improvements to deliver high quality SAP solution.
 Ensure that level of communication between business SME and onsite team members is appropriate so that business and SAP functional requirements are clearly understood.

Risk #8: Inaccurate or incomplete work estimation on SAP projects resulting in cost overruns and schedule delays
Several projects fail or end up being prolonged due to cost overruns as a result of work effort being inaccurately or incompletely estimated. SAP projects have been no exception to this situation. Work estimations should be done at various points on a SAP implementation. Blueprint work estimation should be done during project planning phase. After SAP software fit gap is complete and RICEF inventory is finalized, the work effort should be estimated for design, build, testing and deployment of your SAP system. So from where do these estimation risks surface? Often project estimators from the systems integrator do not include the client employees (SME, analysts, etc) that are required to be consulted or complete the deliverable. Estimates in producing a deliverable should include time required from SI as well as client resources. The work effort for SAP solution related items should directly be tied to a RICEFW object or SAP configuration object. Legacy or external systems remediation effort to integrate these systems with SAP should be added to the above estimates. Sometimes work effort associated with mandatory SAP work streams such as hardware setup, security, systems administration (SAP BASIS) and network administration is often missed. Note: Re-estimations should be done in early realization phase if you realize that RICEFW objects are taking longer than expected due to project cultural or operative barriers. This should ideally be resolved by project leadership and if not addressed can delay the entire project. There may be some RICEFW objects especially a select few Enhancements that are super complex and as such these should be estimated separately. Because these super complex objects may take much longer to be designed and developed.

Risk #8 Mitigation
 Make sure each RICEFW, configuration and other work object is classified as “High”, “Medium” or “Low” and work effort includes design, build and testing effort from system integrator as well as client resources.
 It may be a good idea to do parallel prototype of 2-3 RICEFW objects to convince the project leadership that RICEFW development can be optimistically delivered as per the estimates.
 Verify that project estimates include hardware setup, network administration, security and SAP systems administration effort.
 Estimates should also include duration based work effort components such as PMO, OCM/Training and testing.
 It is very important that “super complex” enhancements are estimated separately and not by the SI estimation tool. This will allow for accurate reflection of work effort for completion of these complex enhancements on the project plan.

Risk #9: Choosing an incorrect Systems Integrator with limited track record of successful SAP systems delivery in “specific SAP industry solution” can lead to project failure on multiple fronts
This is one risk that can be avoided if you follow the principles on which I basically operate on any SAP project. During early blueprint and there on your project leadership may realize that you have not chosen the best SAP systems integrator for variety of reasons. These reasons may include poor quality resources that lack proper SAP knowledge, project delays, and poor project execution and so on. It can be very painful and cost prohibitive to change your SAP systems integrator at the end of a phase and more so in the middle of a project phase. As such it is very important to carefully evaluate, verify and strategically engage a SAP systems integrator for your project during project pre-planning phase.

Risk #9 Mitigation
 Verify that SAP systems integrators (vendors) bidding for your SAP implementation have implemented specific SAP solutions at two or more customers in your specific industry.
 Conduct reference calls with these customers. Check how these vendors have performed on these other SAP projects. Was the delivery in line with original project budget and timeline?
 Ensure that SI or vendor partner and senior executives that will be part of your project also have been part of at least one of these prior SAP implementations. It is important that senior executives and client partners have successful track record in delivering SAP transformation projects in your industry.
 Include financial and corrective penalties in the Statement of Work (SOW) in case the project milestones or Q-gates are delayed.
 It is absolutely crucial to include clear and detailed scope of work in the SOW. SOW should not have any ambiguities that can compromise the successful delivery of project.
 Engage an independent SAP project advisors right from the beginning of the project if your project budget allows.

Risk #10: Inefficient Project Management Office (PMO) with poor project visibility, deliverable tracking, issues/risks management and communication shortfalls

This is one area where I have hardly compromised when setting my expectations from the PMO of the SAP projects that I served. PMO is the backbone of any IT transformation project and most of what is mentioned here about PMO applies to SAP as well as non-SAP projects. PMO should serve as the single source of truth to project an accurate project status at any point in time. It should provide full visibility to project status by presenting the clear picture of work activities, tasks and deliverables progress. I expect the SAP project manager and PMO team to work with individual business, IT and other teams and their underlying work streams to gather correct work progress and reflect the same in the project management tool such as MS Project. A highly effective PMO is the one that deploys, monitors and enforces the proper usage of tools and methods and properly manage time spent by project resources to deliver the tasks as per plan. PMO should ascertain that all project risks and issues are entered into risks and issues management tools and ensure resolution of these items in a timely manner as set in the project charters.

Risk #10 Mitigation
 Verify that PMO is working with good project plan with well defined work breakdown structure that depicts accurate progress of tasks and deliverables.
 Every week PMO team should work with team leads and update the project plan. Any delays in completion of tasks and deliverables should be reflected in the team leads weekly report and also highlighted in the weekly PMO meeting.
 SAP Project Manager (or also referred to as PMO Lead) should work with the programme manager or Project Director, project sponsor and independent project advisors to discuss project progress and also seek recommendations to bring project back on track in case of delays.
 In the blueprint phase, PMO must ensure that all business requirements, BPRD documents, SAP solution design, SAP solution architecture, organization change management strategy, etc are reviewed and approved by the business or IT lead and other corporate stakeholders.
 In the realization phase, PMO must ensure that each RICEFW functional and technical design, unit tests and UAT are approved by the customer business and IT teams.
 No deliverable should be set as “complete” in the project plan unless it is reviewed and fully accepted by the business leads.
 Project capital and expenses should be accurately tracked as per guidelines from leadership and CFO (Chief Financial Officer). Total project costs incurred should be reported on a weekly basis in the project leadership meeting.

APA (Accounts Payable Automation)

November 27, 2013

In the current AP world there are four elements necessary for AP success: Automation, Collaboration, Visibility and Control.

Automation

Automation is a critical foundation to lowering costs and streamlining each of the four AP sub-processes: invoice receipt, approval and inquiry, validation and reconciliation, and settlements. Technology solutions to manage invoices and workflow, and electronic payment methods reduce the inefficiency of manual and paper-based processes.

Collaboration

Cross-functional coordination among key stakeholders such as accounts payable, procurement, finance, treasury and suppliers creates an environment where key information flows easily between these stakeholders. Without this, treasury can’t make optimal capital decisions; procurement can’t identify negotiation opportunities with key suppliers, and suppliers and internal stakeholders can’t track invoice processing status. It will also be difficult to set up different approval and routing rules based on different types of invoices or supplier arrangements, such as PO-based, non-PO-based, preapproved and supplier maintenance.

Visibility

Visibility into liabilities and operating expenses is the basic requirement for most major functions within an enterprise. It is used to give an overall view of operations and establish standards on which to base strategies for performance improvement.

 

Research has shown that best-in-class organizations are 43% more likely to have enterprise-level visibility for AP transactions. The rest suffer from higher transaction costs and longer cycle times. Not seeing material liabilities that are not yet entered impact the timing and accuracy when closing accounting periods.

 

For a typical AP department, enterprise visibility remains out of reach. A high degree of visibility brings substantial advantages, including:

 

Low transaction costs;

Shorter processing cycle times;

 Decreased financial risk;

Shorter response times – improved productivity by reducing time wasted in low-value activities;

Improved forecasting and management of near-term cash management requirements;

Greater ability to monitor billing discrepancies and overpayments, recognize unclaimed negotiated discounts, contracted payment terms, early payment discounts, and late penalty fees.

 

Control

 

Good audit controls help organizations enforce corporate policies and achieve contract compliance. Audit controls ensure that AP transactions are processed in a way that complies with policies, procedures and regulations. They help reduce late payment fees, capture negotiated discounts and early payment discounts, eliminate duplicate invoice payments, and prevent fraudulent payments. Research2 has found the exception rates in top performing firms are 85% lower than other enterprises.

 

Benefits

 

An automated AP solution streamlines and drastically improves performance by utilizing e-invoicing, scanning and workflow, online tracking and reporting capabilities, electronic invoice dashboards and supplier portals, supplier networks, payment services and spend analytics for all invoices.

 

Using an automated AP solution, organizations will successfully drive transformation of their accounts payable departments to overcome the challenges of manual and paper-based processes.

 

What are the “Must Haves”?

Key areas required by organizations to ensure that a solution covers current and future needs as the process matures, include:

 

Automate your process: From arrival to post and archive, with efficient workflow to streamline verification and exception handling;

Any format, any source: Physical documents, electronic documents, and document images, via mailbox, email, fax and file transfer;

Improve what you have: Integrate with the major ERP/financial system of your choice;

Increase visibility: Improve your cash flow and invoice management;

Better control of received and invoiced goods, automatic purchase order matching, optional automatic posting of invoices, enhanced security, less manual work, shorter total processing time, decreased total cost for supplier handling and early notification of errors;

Improved day-to-day information on financial status (regarding current projects, for example) and basis for business decisions. This saves a substantial amount of valuable time at the end of every month, quarter and year.

Shared service centers: A centralized or shared services approach will help ensure that AP tasks are streamlined and standardized; best practices are documented and shared, and AP technology budgets are consolidated.

 

And not just for Large Organisations.

AP automation technologies have been limited to larger companies until recently. Now there is evidence that small and medium sized businesses are adopting the technologies for the following reasons:

 

A competitive business environment means even small and medium-sized businesses need to focus on reducing processing costs and increasing efficiencies for invoices and employee expenses.

Streamlining the AP process has become extremely important in a tough economy where cash flow and greater control over payables is critical.

An increased interest in early payment discounts is driving smaller organizations to investigate tools and technologies that enable them to shorten their invoice receipt-to-approval cycles.

On-demand and Software-as-a-Service (SaaS) delivery models have lowered the initial cost of implementing AP solutions and make them easier to maintain.

The convergence of electronic invoicing and front-end invoice imaging gives organizations a single, comprehensive solution that can manage both paper and electronic invoices through a common process.

Value added-services delivered by solution providers for supplier recruitment tasks mean that buyer organizations can engage suppliers more quickly.

 

So which Type of Solutions make the most sense?

 

Electronic invoicing solutions automate the invoice reconciliation and payment process and address most invoice types.

 

Workflow and imaging solutions manage all aspects of in-house invoice scanning and documentation and provide an effective electronic archival system. They are often part of a cross-functional enterprise solution.

 

Payment automation platforms specialize in accounts payable and accounts receivable processing. They offer relief in disbursements for payroll, benefits, regulatory and tax issues, as well as intra-company transfers. These solutions range from automated clearing house (ACH) and general payment processing to company-wide AP solutions.

 

Enterprise financial solutions, which manage the budget and general ledger of an enterprise, consist mainly of Enterprise Resource Planning (ERP) providers. They typically offer functions such as a general ledger, and sometimes more advanced capabilities like supply chain auto-reconciliation and AP workflow.

 

Purchasing cards (p-cards) are designed to streamline the front (purchasing) and back (payment and reconciliation) ends of the procure-to-pay process. They introduce greater levels of control and visibility for management of low-cost, high-volume categories.

 

Supply chain finance solutions provide full AP invoice dashboards, so enterprises can manage payables more easily. With ERP integration and supplier portal capabilities, these solutions can help move to an automated AP platform.

 

Treasury management services offer advanced financial administration by consolidating cash forecasting and handling foreign exchange affairs. These services provide management for deals and trades, and they also provide analytics and risk management.

 

The Sardine Strategy 2013 for 2014

November 19, 2013

sardine-schooling-edpdiver

Once again I have resurrected an older post which I believe is still extremely relevant this year as it was towards the end of last year. What I am a little disappointed in is that there are people that have not heard what is being said!  Before you embark upon any business improvement in 2014, make sure that you know where you want to go and understand the implications of your actions. Without moving as one, you will surely fail. Don’t lose direction!

What is the latest buzz in the supply chain world I was asked at a recent SAP Conference, I replied there is plenty of buzz in the SCM world but all this hype needs to be underpinned by a good solid supply chain strategy.

Have you heard of the “Sardine Strategy” ? the questioner looked perplexed at my question! I will elaborate for schooling fish, staying together is a way of life. Fish in a school move together as one, for schooling fish the “move as one” trait is innate. Separation means likely death!

For Global Supply Chain, misalignment – failure to move as one – means poor service, high inventory, unexpected cost, constrained growth and profits, finally resulting in loss or market share and possibly reputation. Once market share and reputation have been damaged they are difficult to repair.

So what are the common causes of misalignment – failure in supply chains to “move as one”?

I offer a list of some 15 common causes that have plagued companies for many years and still do today, I am sure that the list is non exhaustive, but I am doubly sure that the readers can equate to one or more of these businesses today.
1). Lack of Technology investment plan.
2).Little or no return on investment (ROI)
3).Isolated supply chain strategies.
4). Competing supply chain business improvement projects.
5).Faulty sales and operations planning.
6).Failure to meet Financial Commitments.
7).Lack of support and specialized expertise.
8).Mismatch between Corporate Culture and ERP.
9). Under utilization of existing technology.
10).Vaguely defined goals.
11).Impact of mergers and acquisitions.
12).Mismanagement and poor standardization of business processes.
13). Extension from supply chain to the value chain.
14).Running out of ideas for new improvement projects.
15).An organisation that defies effective and efficient supply chain.

We could discuss each of these in great depth, but space and time is limited, however if you want to discuss any of these causes you have identified just drop me a line

Where does ERP failure really come from?

November 18, 2013

Here is a Question that is asked over and over again, where does ERP failure really come from? Ultimately, most problems can be summed up in one word: People.

Most projects begin life with the hopeful enthusiasm of anticipated triumph and success. However, success requires planning for details that do not become relevant until much later in project; training is a perfect example

In a number of cases the losses are blamed, at least in part, on their employees not understanding how to use their newly installed SAP ERP system, which they said worked just fine.

So, why is this? Well, basically, in the beginning of any big, shiny new project, what you have is a great deal of excitement over the benefits that it will bestow upon your organization streamlined processes, bottom-line savings, top line growth, more efficiency, reduced waste, better customer service, etc. The problem arises when this leads to a “hurry-up-and-get-things-done” approach.

Too much of the time companies are overly aggressive when they set their initial timelines, they see the statistics that show that many projects go over budget or take longer than expected, so they end up wanting a very aggressive project plan just so they can manage the time and budget.

Maybe your company has a history of talking-the-talk but, walking-the-walk? Different story! “This time it’s going to be different!,” exclaims the CEO slapping the table for emphasis and everyone’s on board. Here you go charging ahead, selecting a vendor, shun due diligence, and fail to define clear business requirements and goals. Perhaps you even know you don’t understand your business processes as well you need to but, “well now, ERP’s are designed to fix all that, Correct?

So how to you combat this? It’s simple: don’t do it! Rushing an ERP project to save time and money will cost you more in the end than you will ever save up front.

Done properly ERP can and will transform your business by automating and re-engineering its beating heart: its business processes. It is, therefore, in your best interest to take the time to understand how your business actually runs.

It is so so critical to understand the level of resource commitment the project will take.
So the objective is understand what you do as a business, understand what your systems currently support or don’t support and then have the vendors or integrators show you how their system can best support what it is you’ve brought to the table.

One of the biggest elements of any implementation where executives often fail is under estimating the time it will take to get the project done. Understanding things like time-to-value, change management, adoption, employee training, etc. are all down-played in favour of the perceived benefits the software will bring.

Here are a few suggestions of do’s and don’ts that will help:

Develop your own benchmarks; don’t rely on the vendor’s. Vendors can supply you with templates and best practices that can take you a good part of the way but you still need to define what constitutes success and failure, progress and set-backs, deadlines and must-haves, your “as-is” state verses your ideal “to-be” state.

Don’t rely on your vendor or SI to handle change management. It’s your company, so it’s your culture that has to change, not theirs. Change management is up to you and the difficulty or ease of this process is directly affected by expectations set early on. If you think it’s going to be easy and it’s not, then you are going to be in for some sleepless nights.

Define your business processes up front. Don’t’ let a vendor’s software define them for you. Most companies have no real idea how their business processes work in practice until, someone resigns. Suddenly all of that problem solving and expediting wisdom is gone. No software can replicate that knowledge. Find that someone! Talk to that someone, preferably in the beginning of the process, not when you’re trying to get that someone back.

All of this will be more time consuming up front, however will save lots of heartache and money at the back end when you find yourself fixing what should never have been broken in the first place.

It’s my belief some of the essential ingredients first require a strategy and a direction. So there has to be an earmarked plan and with that plan comes budgeting of time, resources and dollars to invest in that plan because a lot of corporations take a real penny pinching approach and it ends up costing them many times more than they ever anticipated as a result of that.

The Deep Web (The Dark Net)

November 5, 2013

Most of us know little or nothing regarding the Deep Web or the Dark Net, just two of the names for that area of the Internet that harbors the possibility of anonymity for its users or can enable search results for illegal drugs or pirated porn. However, there is an ever growing Deep Web/Dark Web community which has touched us in some shape or form. I am guessing here but has anyone won the lottery recently or been bequeathed a fortune and all you have to do is supply your details and whereabouts?

How did the Dark Web come about?

During 1995 at the University of Edinburgh, a teenager named Ian Clarke wrote a thesis for his computer science course proposing a revolutionary new way for people to use the Internet without detection. This project was called “Distributed, Decentralized Information Storage and Retrieval System”. The idea was that by downloading unique software (which was to be distributed free) anyone could chat online, share files, read or set up a website with almost complete anonymity.

Unfortunately the tutors were not too impressed, but this did not stop the student from going ahead with his project releasing the software called “Freenet” in 2000. Since then, millions of copies of Freenet have been downloaded, which remains readily available on several websites. Simply do a Google search for “Freenet download” to find it.

Entering the Realm of the Deep Net

Once the file has been downloaded, installation takes barely a couple of minutes and requires minimal computer skills. There you are a previously hidden online world where you can find resources such as “The Terrorist’s Handbook: A practical guide to explosives and other things of interest to terrorists”. Freenet is also the portal to accessing pirated­ copies of books, games, movies, music, software, TV series and much much more.

What started as a seemingly innocent project has today become a means for a plethora of online criminal activity from creating and sharing viruses to accessing and distributing child pornography all anonymously.

The Internet has always been associated with openness and is often labeled as the ultimate form of freedom where free speech, free access and lack of censorship have prevailed (just look at the internet society’s tagline “The Internet is for everyone”). Yet where do we draw the line when it is simply becoming easier and easier to engage in online criminal activity without been traced?

Putting it into perspective, the Dark Web has grown so fast that it is estimated to be at least 500 times larger than the surface web.

So what is the difference between the Deep Web and the Surface Web?

Simply put, the web is defined as a collection of hyperlinks that are indexed by search engines. In other words, the pages/content that appears when we do a Google search, is the Internet as we know it, this is called the surface web.

The Dark Web, also known as the deep web, invisible web, and dark net, consists of web pages and data that are beyond the reach of search engines. Some of what makes up the Deep Web consists of abandoned, inactive web pages, but the majority of data that lies within have been crafted to deliberately avoid detection in order to remain anonymous.

How deep is the Dark Net

The Internet has changed significantly over the years, but researchers are still only beginning the plunge to the depths of the Deep Web. The bottom line is that there is simply too much data available for any search engine to index the entire deep web.

Coupled with this issue is the deliberate use of invisible web space by individuals who do not want to be found. This is the origin of groups of criminals who sent out millions of spam e-mails suggesting that you have won the international lottery before quickly disconnecting. No matter what developments are made toward catching crooks they will always find new ways to remain hidden.

Is there any light down there?

It was never the intention to create a breeding ground for online criminals, which is sadly the predominant direction that the Deep Web seems to have taken.

There are secretive parts of the Internet that were specifically designed for secret services and law enforcement officers to surf questionable websites and services without leaving tell-tale tracks. Perhaps the domain of the dark net would make sense in oppressive regimes such as China­ where the government goes to extreme lengths to censor images that contain large expanses of supposedly naked flesh. It could certainly have a positive impact in countries such as Iran allowing people to rally support against oppressive governments without fear of being apprehended.

It is a worrying to think that due to the size and rapid growth of the Deep Web there is pretty much no way of stopping it. However, it may not be as bad as we all might think, but there is definitely a large enough criminal element to warrant concern.

Ten Tips on how to sell Compliance in the Organisation

October 28, 2013

It probably seems to you like every time you want to talk about Compliance, everyone runs away and hides, they ignore you and hope you go away, or they fuss and moan. Compliance is a fact of business life, however, Your company must comply with:

Your Customers requirements (quality, safety, performance specifications, quantity, price, prompt delivery, etc.); Industry or other standards and guidelines (ISO 9001, IRFS, etc.); and/or
Regulations (e.g., 8th EU Directive, Food Safety Modernization Act) in order to get or to keep business. Therein lies the problem: compliance is like healthy eating or exercise. We know we have to, but well, it’s so hard to either make the time or get enthusiastic about it! Why is it that “have to” and “want to” always seem to be inversely proportional to one another?

How do you sell yourself and your employees on the notion that compliance is something you want, not something you merely put up with? How do you turn “got to” into “want to”?

First, you have to…

Sell yourself on the idea. You’ll find in life, that is, if you haven’t already that if you don’t have a deep and firmly held belief in your company, your product, or your people, you won’t sell your product or your service. If you lack enthusiasm, conviction, self-discipline, vision, perspective, and some of the other characteristics that define leadership, you won’t have many followers.

Your customers are your ultimate critics. If you don’t meet their requirements, you’re out of business. It won’t matter what other requirements you fail to meet if you fail to meet your customer’s. Have your priorities in order, listen to your customers first.

Include your staff in the development of Policies and Procedures that will ensure your company’s compliance, because: (a) you can’t do it all by yourself; (b) they know more of the day-to-day tasks, operations, and processes than you; and (c) you need to show that you value and trust their judgement if they’re to grow (i.e., micromanagers never win).

Give everyone in your firm the resources they need to do their jobs effectively.

Ensure that your employees are more than adequately trained and experienced.

Make sure they know what they’re doing and more importantly why they’re doing it.

Keep the lines of communication open all the time. Communicate effectively and continually with all levels of your organization.

Get out of your office! Regularly address your employees first hand, directly and openly.

Listen, and then turn what you’re hearing into something your employees — and your customers want to act upon.

Make a habit of meeting with suppliers, subcontractors, and everyone who has a hand in getting your product or service into the hands of your customers. You might not be able to do this often but you shouldn’t let a year go by without visiting with your valuable partners. Communication is key!

Look at failures as opportunities for improvement. Don’t go looking for the guilty party every time something doesn’t go according to plan! You want to keep failure to a minimum, yes, but keep things in perspective. Not every mistake requires Draconian countermeasures!

Share success. Compliance goes beyond merely observing standards or laws, compliance can help you win business! When it does, spread the wealth. Acknowledge the part everyone played in making your company a success, especially those who had a direct hand in your victory.

Sell yourself, then sell everyone else on the importance and value of compliance.

Make them want it! Your customers do.

Warehouse Management Best Practice.

October 25, 2013

Companies are constantly trying to find ways to improve performance and warehouse operations is area where supply chain managers can focus to gain maximum efficiency for minimum cost. To get the most out of the operation, a number of best practices can be adopted to improve productivity and overall customer satisfaction. Although best practices vary from industry to industry and by the products shipped there are a number of best practices that can be applied to most companies.
When considering the level of effort involved in warehouse operations, the greatest expenditure of effort is in the picking process. To gain efficiencies in picking the labor time to pick orders needs to be reduced and this can achieved in a number of ways. Companies with the most efficient warehouses have the most frequently picked items closest to the shipping areas to minimise picking time. These companies achieve their competitive advantage by constantly reviewing their sales data to ensure that the items are stored close to the shipping area are still the most frequently picked.
Warehouse layout is also important in achieve greater efficiencies. Minimising travel time between picking locations can greatly improve productivity. However, to achieve this increase in efficiency, companies must develop processes to regularly monitor picking travel times and storage locations.
Warehouse operations that still use hard copy pick tickets find that it is not very efficient and prone to human errors. To combat this and to maximise efficiency, world class warehouse operations had adopted technology that is some of today’s most advanced systems. In addition to hand-held RF readers and printers, companies are introducing pick-to-light and voice recognition technology.
In a pick-to-light system, an operator will scan a bar-coded label attached to a box. A digital display located in front of the pick bin will inform the operator of the item and quantity that they need to pick. Companies are typically using pick-to-light systems for their top 5 to 20% selling products. By introducing this system companies can gain significant efficiencies as it is totally paperless and eliminates the errors caused by pick tickets.
Voice picking systems inform the operator of pick instructions through a headset. The pick instructions are sent via RF from the company’s ERP or order management software. The system allows operators to perform pick operations without looking at a computer screen or deal with paper pick tickets. Many world class warehouse operations have adopted voice picking to complement the pick-to-light systems in place for their fast moving products.
Although many companies will not be able to afford new technologies for picking, there are a number of best practices that can be adopted to improve efficiency and reduce cost.

Collaboration in SCM

January 16, 2013

Over the years, many technologies have evolved to support both asynchronous and real-time collaboration. Most of the older technologies, such as teleconferencing, video conferencing, e-mail, etc., have major limitations that lower their value in product development environments. The newer and still-evolving technologies that enable PLM allow the management of product information and the processes that are used to create, configure, and use the information in a manner never previously thought of before.
We talk a lot about collaboration, but do we really understand what it means? In general, collaboration is an iterative process where multiple people work together toward a common goal. Methods of working collaboratively have existed as long as humans have joined together to accomplish tasks that could be done better by a team than an individual. Early man is probably the best example of collaboration when hunting for food for the village or the tribe.

There are two modes of collaboration: synchronous and asynchronous. Users working in an asynchronous manner carry out their assigned tasks and then forward the data to the next person. This way of working is serial in nature and only allows users to participate one at a time. Communication among collaborators is normally carried out using telephone or e-mail. Effective collaboration requires an area of storage for information from which product definition data can be shared with all those that require it. This shared area is commonly referred to as a data vault. Flow control and task execution is performed in an asynchronous way using workflow and project management tools. These tools allow data to be routed to users and progress to be monitored.

Synchronous or real-time collaboration enables users to view, work with 2D (e.g., specifications, drawings, documents, etc.) and 3D data (e.g., mechanical CAD models), and carry out interactive communications with each other in real-time. In addition, PLM-enabled collaborative solutions often support the ability to view, rotate, add notes and annotation pointers, and some also offer functionality to change the 3D design model data. This provides the same communication effectiveness as having all participants in the same room, at the same time, looking at the same data.
The following describes some of the processes commonly supported by PLM-enabled collaborative technologies.

Supply Chain Management—The move to a partnership-oriented supply chain means that suppliers, partners, sub-contractors, and customers are all involved in product definition. For companies to embrace the true potential of the distributed supply chain, collaborative tools can be used to manage data and processes across a distributed environment.

Sales and Bidding—Opportunities exist for sales, engineering, purchasing, and manufacturing to engage in collaborative sessions where product options, alternatives, and concepts are reviewed by each discipline at the same time. This is faster, more efficient, and can produce more accurate and cost-effective bids.

Maintenance and Support—The application of collaborative tools in maintenance and support activities is gaining acceptance in a number of different sectors such as aerospace and defense, automotive, process, and machine tools. For example, animation and simulation tools are being used to demonstrate how products are operated and maintained.

Change Management and Design Review—Adopting a different design review process, where project teams join a shared collaborative review session can result in significant benefits as potential conflicts and errors can be identified early in the product development lifecycle.

Senior Managers in the business world understand economic cycles are a known fact of life. The key to success is the way managers and organizations adapt to these cycles. Since they are a fact of life, we know that we can’t just ignore downturns and hope for a better day. So instead, those that are successful learn how to become more efficient while still ensuring that they deliver the best value to the markets they serve (i.e., making available the right product, at the right price, to the right market, at the right time, at the right quality, (The 5 Rights!)).

Business Process Re Engineering

January 8, 2013

Business process reengineering (often referred to by the acronym BPR) is the main way in which organizations become more efficient and modernize. Business process reengineering transforms an organization in ways that directly affect performance.

The Impact Of BPR On Organizational Performance
The two cornerstones of any organization are the people and the processes. If individuals are motivated and working hard, yet the business processes are cumbersome and non-essential activities remain, organizational performance will be poor. Business Process Reengineering is the key to transforming how people work. What appear to be minor changes in processes can have dramatic effects on cash flow, service delivery and customer satisfaction. Even the act of documenting business processes alone will typically improve organizational efficiency by 10%.

How To Implement A BPR Project
The best way to map and improve the organization’s procedures is to take a top down approach, and not undertake a project in isolation. That means:
• Starting with mission statements that define the purpose of the organization and describe what sets it apart from others in its sector or industry.
• Producing vision statements which define where the organization is going, to provide a clear picture of the desired future position.
• Build these into a clear business strategy thereby deriving the project objectives.
• Defining behaviors that will enable the organization to achieve its’ aims.
• Producing key performance measures to track progress.
• Relating efficiency improvements to the culture of the organization
• Identifying initiatives that will improve performance.
Once these building blocks are in place, the BPR exercise can begin.

Tools To Support BPR
When a BPR project is undertaken across the organization, it can require managing a massive amount of information about the processes, data and systems. If you don’t have an excellent tool to support BPR, the management of this information can become an impossible task. The use of a good BPR/documentation tool is vital in any BPR project.
The types of attributes you should look for in BPR software are:
• Graphical interface for fast documentation
• “Object oriented” technology, so that changes to data (eg: job titles) only need to be made in one place, and the change automatically appears throughout all the organization’s procedures and documentation.
• Drag and drop facility so you can easily relate organizational and data objects to each step in the process
• Customizable meta data fields, so that you can include information relating to your industry, business sector or organization in your documentation
• Analysis, such as swim-lanes to show visually how responsibilities in a process are transferred between different roles, or where data items or computer applications are used.
• Support for Value Stream mapping.
• CRUD or RACI reports, to provide evidence for process improvement.
• The ability to assess the processes against agreed international standards
• Simulation software to support ‘what-if’ analyses during the design phase of the project to develop LEAN processes
• The production of word documents or web site versions of the procedures at the touch of a single button, so that the information can be easily maintained and updated.

Conclusion
To be successful, business process reengineering projects need to be top down, taking in the complete organization, and the full end to end processes. It needs to be supported by tools that make processes easy to track and analyze. If you would like help with your BPR project, please Manage to Supply
• Business process reengineering is a huge step for any company, though one that can bring equally significant rewards when properly implemented. Be sure to think your decision through thoroughly and proceed only after you’ve done sufficient research.
• Should you decide to act as your own business process engineer, realize that you’ll need adequate BPR training and excellent business process engineering software to successfully pull it off. You’ll need to develop the skills necessary for creating a business process map redesign that not only meets your company’s unique needs, but also adequately addresses your prior business process problems.