Posts Tagged ‘Continuous Learning’

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.

Advertisements

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.

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.

Mobile Learning (Mlearning)

December 24, 2012

Today’s knowledge society, people are connected almost 24 x 7 x 365 to their mobile devices. E-mail, voice mail, instant messages, and video conferencing are all available with the touch of a button almost everywhere across the globe. No matter what business or industry you’re in, people need to be connected. As a consequence of the need for connectivity, more and more people are leveraging mobile devices, in more ways than one. Additionally, because of the wide adoption of social networking, these types of devices have become more affordable and thus more readily available to the global population.
However, it’s not a new phenon at all the use of mobile devices, it’s just that technology has and is still rapidly advancing. Years ago I wrote an article about replacing your laptop with a mobile device, the article ‘How to lose 12 kilo’s in 15 minutes’ (http://www.digitaloman.com/indexb130.html?issue=2&lang=en&id=20_1) showed that it was possible to go on a trip and stay connected with a mobile device and be enabled to do business whilst on the move. Today’s road warrior is no different, but the underlying technology and devices are much smarter, more powerful and far cheaper than ever before.
Salespeople away from their offices have instant access to vendor information, numbers, pricing, etc. Area supervisors can easily access information about the employees they manage in various geographical locations. C-level managers travelling on business can easily manage their agendas.

How about Mobile learning, or m-learning as it is termed, focuses on the mobility of the learner, allowing him/her to interact with portable technologies and take in bite-size portions (called nuggets) of content, learning bits at a time. M-learning is convenient, as content is accessible from virtually anywhere. And the lightweight portability of the device removes the need for learners to carry around books and notes.
M-learning, like e-learning, is also collaborative. The Learner can easily share advice with or ask questions to others using the same content. This leads to instant feedback from peers, co-workers, managers, etc. On a recent visit to a training company (who will remain nameless) I witnessed to my horror that still today binders were being produced when updates occurred in the area of compliance monitoring. Nobody whoever takes the course can carry all the binders around with them to allow them to get updates on the processes.
Teaching experts have known for years that repetition is one of the two best ways to ensure that what we’re learning about sticks in our memory; the other is relevance. With nearly everyone carrying a portable device these days, mobile devices have become the perfect tool for providing regular reminders to help individuals remember and retain information. In a past project, in fact the implementation of SAP in a Aluminium Smelter M-Learning would have been the perfect tool to train staff in the smelter, however, Mobile devices cannot be used in a smelter so in this case a pocket book was developed. But where there is the opportunity and safety is of concern, companies should look at the possibility of the use of this technique.

This all sounds wonderful, doesn’t it? But are there some possible downsides to mobile learning? Let’s take a look at some of the questions this fast-growing trend has raised.
What types of learning can I access through my mobile device?
• compliance training
• performance support
• policy/regulation updates
• testing and quizzes
• job aids and training
• surveys and polls
• checklists
• … and more
How Effective Is M-learning, Really?
Learning experts have known for years that repetition is one of the two best ways to ensure that what we’re learning about sticks in our memory; the other is relevance. With nearly everyone carrying a portable device these days, mobile devices have become the perfect tool for providing regular reminders to help individuals remember and retain information. But how effective is m-learning, really?

One of the keys to successful training is creating the proper learning environment. Can mobile learning be part of that success? I believe it can. The bite-size portions that learners take in via their mobile session can help increase their level of understanding—for one thing, they’re not bombarded with information overload. Moreover, the effective and efficient advantage of ubiquitous learning means learners are ready at any time (and from anywhere) to take a course, survey, or quiz—they don’t have to wait for the class to begin or until they get home to log on to their desktop computers.

But, because mobile learning is still in its infancy, it is very difficult to gauge its use and effectiveness once deployed. As such, this greatly limits the ability for learning administrators or instructors to gain executive support on such an initiative.

What Can M-learning Do for Me?
Through mobile learning, organizations can communicate with their mobile workforce as well as engage employees in rich learning content that is specific to their jobs.
What type of mobile device can I use for learning?
• mobile phone
• smart phone
• Blackberry
• Android
• iPhone/iPad/iPod Touch
• Pocket PC
• Netbook
• tablet
• … and more
Mobility allows learners to do the following:
• access information from different locations, through different wireless capabilities
• use audio/video (streaming technology) to enhance their learning experience
• manage and track their course enrollment and progress
• access and manage their learning in the format that best supports their needs, accessing course content through either a dedicated application or a device’s browser
• learn easily on the run, through the ubiquitous nature of the mobile device
• review information quickly and easily, rather than engage in a prolonged or deep type of learning—10-to-15 minute chunks of learning, at most, are recommended. Unfortunately, people don’t sit still long enough to take in more than that on a mobile device

What about Technical Issues?
In the past, learners, developers, and administrators faced plenty of technology, usability, and organizational challenges that prevented the widespread commitment to and adoption of mobile learning. These are some of their concerns:
• Security—Proprietary content needs to be secure. Because of their size and portability, mobile devices are easy to lose, subject to damage, and more likely to be stolen than desktop systems, increasing the possibility of exposing confidential company data.
• Content presentation—A lack of technology consistency exists among devices, preventing content, such as video, from being properly displayed, and forcing organizations to dedicate valued resources to reconfiguring content for multiple devices.
• Screen size—Most mobile devices are quite small (except for the recent entrant iPad), making it difficult to view full screens of data without the need to scroll. Picture resolution can also be a factor; graphics should be in PNG format, rather than BMP format, which is smaller for better viewing.
• Usability—As most mobile devices use touch-screen technology, information needs to be organized and easily navigated with the touch of a finger. The interface between screens needs to be quick, otherwise learners will lose interest very quickly.
• Bandwidth—The richer the media, the more likely to be download and bandwidth issues. When people experience slow data exchange, they have difficulty absorbing what they’re learning.
• Support—Mobile learning programs often require new staff and/or skills to integrate and operate. Specialized development tools are also needed, requiring considerable training to develop content.
With the addition of new technologies (e.g., information receivers, cameras, radio-frequency identification [RFID] readers, etc.) and more stringent company policies on the use of portable devices for work purposes, some of these technical challenges are beginning to dissipate. I believe the bigger challenge lies in the global adoption of this technology in business. Many organizations are still unsure of how mobile learning will affect their bottom line.

Conclusion
Let’s face it, with everyone joined at the fingertip to their mobile device, it only makes sense to make use of a growing trend and add learning to our already favorite pastime of mobile computing. The use of mobile devices seems a natural fit for distributed learning and field activities, as handheld technology can not only accompany the learner virtually anywhere, but also provide a platform that is always connected to data sources.
The popularity of mobile technology makes this an option worth exploring in a company’s training strategy. Today’s organizations should feel confident in developing and deploying mobile learning programs that support their key corporate initiatives. Remember, however, that mobile learning should not be a replacement for other modes of learning, but simply an extension.
I’ve just scratched the surface on the topic of mobile learning in this post; there is a lot more to be said about this rapidly growing trend.
For further reading on the subject of m-learning and mobility, I recommend the following two books:
The Mobile Learning Edge: Tools and Technologies for Developing Your Teams
Portable Communities: The Social Dynamics of Online and Mobile Connectedness