ERP Software done correctly can be a great tool for improving a business.  Done badly, it can demoralize employees and drive down business results.

Case-in-point:

ERP Software should enable business processes, not torture the employees.

Now from a business standpoint this is all well and good. But what about the employee? A lot of days, clocking and clocking out I felt as though it did not matter whether or not I was even there. There were simply no jobs to be done for entire weeks at a time, but that did not change that I had to “clock out” for certain jobs. Of course, a business wants to make sure that all of its employees are being as productive as possible, but clocking out on cleaning out the same area 3 times during a week seemed redundant and absurd. Not to mention clocking out on an activity such as “material handling” or “lean labor” is fairly arbitrary. This of course necessitated a manager to scold me when my productivity levels fell (ie playing Frisbee with a cardboard box in the back). It is important to note that I was simply summer-hired as well. Working full time at a job as a number would eventually get fairly tedious. As one of my co-workers noted to me, they had simply clocked in and clocked out for a couple of weeks and clocked off on none of the jobs they were doing. No one said anything to him. So who’s checking these jobs?”  - Andrew Mellino

Implementing technology to collect data is one thing, but ERP should not be just about the numbers. ERP ideally should be “process improvement enabled by technology.” It should not be a tool to harass the employees. This is a key concept to understand when implementing and going through the design phase. Which processes are broken and which processes are working fine. Once you have defined that, then see where the ERP software can enable best business practices. It is essential that the employees have a buy in and provide feedback to this step.

If you get the employees to buy into the implementation and how it will change their jobs, you will gain the benefits of higher utilization of the system and overall better adoption. If you fail this step, you will have a failed ERP implementation. There is a saying that you should “drive data collection to the source.” This means that you should have the person who is directly responsible for the source of that data be the one who is entering it. When the ERP system is not implemented with the employees in mind, the employees will be unmotivated to use the system, ensure that the data is accurate, or even bother to put in correct information.

With the help of your line employees, design in best practices and work with them to build a system that they will use and will benefit not only them by making their jobs easier, but also benefit the whole company by driving positive results.

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later

Defining your ERP Evaluation Criteria is essential for paring down the vendors and getting to the final choice.  There are two focus areas for determining your selection criteria:

1. ERP Process Evaluation Criteria

Process Criteria is the evaluation tool you would use to determine the flow of data through the system and how it would follow along your established or to-be business processes.  For example, following a process flow of quoting an order, receiving the order, manufacturing or purchasing the product, shipping, and finally invoicing the order is known as an order-to-cash process flow.

By mapping out these processes in a visio diagram or even on a whiteboard, you will have a good understanding of how your business operates.  With this knowledge, your evaluation of various business management software will be a lot easier.  Further, you can see how closely the software’s process flow mirrors your company’s or how disjointed the software is when it comes to your business.

2. ERP System Functional Evaluation Criteria

System Functional Criteria is the detailed list of all of the things you need the system to do, from processing purchase orders, processing a sales order, to invoicing a client and producing financial reports.  These are the nitty gritty things that your system should do.  A good place to start is to evaluate your current system.  What are the functions that the current system does well?  Include these in your list.  What are the things that your system does poorly, include the desired functionality in your list.

Your list should not be 10,000 lines, but rather it should look at those items that make your business unique.  For example, most every business has to cut A/P checks.  So most systems can do that.  So do not list as a requirement that the software should be able to cut A/P checks, rather make your requirement specific to your company, such as “System should be able to cut 3 copy laser checks, with reprint capability.”  That very specific requirement will help you distinguish the vendors from one another.

A good place to start is with an ERP Evaluation Criteria Template.  ERPandMore has many different templates to assist you in evaluating various ERP software venders and have best practices built in.  In using these as a starting point, you will save yourself countless hours in both preparing these criteria templates as well as in differentiating the vendors your are looking at.

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later

One of the most critical plans you can make is to prepare for the worst, especially when it comes to your enterprise software system and the database of all of the company’s critical information. A proper disaster recovery plan is essential, if you are running an ERP system, as it touches all aspects of the company. The plan can be as simple as a backup and recovery strategy, or as extensive as a global hot site fail-over plan. In either case, you need to prepare and test your plan.

Testing the plan is often where people fail. You often plan for the eventuality of a hard drive crash (and thus you use a RAID array), or you plan for the possibility of natural disaster, but what if you have a hidden hardware problem that is corrupting the database a little at a time?

That happened with one company we worked with. A failing motherboard caused problems with the email virus scanner, which in turn corrupted the email store a little at a time, so that it was unrecoverable. What do you do then? Well, in that case it was restore to the point in time that the email store database was usable. So the net impact was a few weeks of data loss. That is one illustration, but what happens if something like that occurs in your ERP database? Again the key is backups.

If backups are so critical, then why do people choose not to bother with testing and restoring them? Many people happily back up night after night, but never try to restore a data file or much less a database. Is it too expensive to have a test server? The real question is it too expensive to not have your ERP data after a disaster? What is the company worth? Millions? A few thousand dollars for a test environment seems like a reasonable investment.

Here are some of the things you need to think through:

1. Backups and Recovery procedures
2. Off-site storage of backup media
3. Security of backup media
4. Remote site backups (In a disaster, can you get the business up if the server site is destroyed?)
5. Personnel (In a disaster, can the right people be there to recover?)
6. Priority levels and potential downtime acceptability
7. Costs

There are some excellent disaster recovery resources on the web on this topic. One article that we liked was on making proper backups for your ERP system. We would suggest that you invest the time to learn more about this topic before it bites you. Remember that disaster always strikes at the most inconvenient time, so make the time now.

ERP Disaster Recovery

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later

Project Management for ERP cannot be understated. It is the essential tool for ensuring a successful launch of a new Enterprise Software system. Understanding the Scope, the Time Frame, the Budget, the People/Resources available, and the goals are all important. Many people use a tool such as MS Project to plan the various stages and tasks to complete.

There is a fundamental difference between planning a project and tracking it. On a project team there are various assignments and tasks that need to be accomplished. MS Project is often cumbersome to track detailed tasks. Especially those that come up in steering committee meetings and even on phone calls.

Being able to track them requires a useful tool to manage all the tasks. This is different than Microsoft Project. MS Project is a great planning tool. But to manage the various sub-projects and tasks, we have started using Nozbe. Check it out. We have put up a link on the sidebar of our site to assist you. Another good resource for various project software is http://www.gtdsoftware.net.

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later

With the drive to being more environmentally responsible, corporate management is (or will be) setting initiatives to reduce carbon emissions. While moving towards Green and reducing the carbon footprint, the question becomes, how do we manage this? Should ERP be modified to include the tracking of carbon emissions?

ERP systems are essentially large accounting systems that capture oodles of data and summarize it in a report to management. Traditionally, they are focused on financial, operational, human resources, and other resource data reporting. It would seem that the next logical step would be to begin tracking and reporting on carbon footprint data. It is surprising though that major ERP vendors have not yet announced this sort of system module or functionality.

With efforts in reducing the carbon footprint focused on the data center, such as reducing power consumption of the server farms, management may be missing the point. FedEx, for example, has reduced fuel bills by up to 30 per cent through better route planning for its trucks. That justifies a lot of server power.

Without the tracking of this sort of key data, management may be focused in the wrong direction. With proper information and analysis, companies can make better decisions and reduce emissions where it gives the most added value. It seems that an ERP system would be perfect in tracking, analyzing and notifying management on the results of their green strategic initiatives.

What do you think?

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later

In this month’s Harvard Business Online, there is a fascinating article on how one bank in Japan rolled out a new business system successfully by breaking all the rules.  By adapting a modular approach and leveraging technologies such as the Internet, they were able to take a dying business and revamp it into a major player in their market.  The article requires accepting their terms of use, but is really worth reading for anyone who plans, manages, or deploys systems.

Radically Simple IT

By designing and deploying enterprise systems in a different way, Japan’s Shinsei Bank turned IT from a constraint into a launchpad for growth.

by David M. Upton and Bradley R. Staats

Enterprise IT projects—both custom and packaged “one size fits most” systems—continue to be a major headache for business leaders. The fundamental problem with these systems is that for the most part, they’re constructed using what programmer and open source champion Eric Raymond dubbed a cathedral approach. Like the great edifices that Europeans erected in the Middle Ages, enterprise IT projects are costly, take a great deal of time, and deliver value only when the project is completed. In the end, they yield systems that are inflexible and cement companies into functioning the way their businesses worked several years ago, when the project started. Despite recent improvements in the flexibility of packaged software, companies often find it exorbitantly expensive and difficult to modify their enterprise systems in order to exploit new business opportunities.

Read the full article here

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later

Software Implementation Projects And Six Sigma
Tony Jacowski

Six Sigma concepts were originally developed for use in the manufacturing sector, but are now increasingly being used in the services sector as well. Use of Six Sigma concepts in the software industry has become quite common, but what many people do not know is that Six Sigma concepts can also be used in software implementation. People who have experience in software implementation projects know that such projects often do not take off as planned and may be subjected to schedule overruns and recurring problems. This is why many software companies opt for employing Six Sigma concepts during the process of software implementation at a clients site.

Common Implementation Problems

The two most common problems faced during software implementation projects include customer requirement problems and schedule estimation problems. By employing Six Sigma concepts in software implementation projects, professionals can better understand the needs and business objectives of the client. This way, they can make sure that the software implementation project is successfully completed within the stipulated timeframe. Employing Six Sigma will also ensure that no additional costs are incurred during the implementation process.

Understanding Client Requirements

Software products are normally designed for increasing the efficiency of a business process in accordance with the goals and objectives of the client. Most of the problems related to the software arise during the implementation stage when the client finds out that the software is unable to achieve desired objectives. This situation arises when the client passes vague information about requirements to software developers or when developers are unable to clearly comprehend client requirements.

Six Sigma helps in avoiding problems during the software implementation stage by bridging the gap between actual requirements of the client and what is eventually understood by software developers. Many people believe that Six Sigma is only limited to the use of statistical methods. What they do not know is that Six Sigma follows a disciplined approach that can solve any type of problem, whether it is quantitative or qualitative. This is evident from software companies that have successfully employed Six Sigma concepts in solving qualitative problems that arise during software implementation projects.

Generating Schedule Estimates

Schedule estimation is another common problem faced during software implementation. Mistakes in schedule estimation can affect the outcome of an implementation project; as such projects are often required to be completed in a specific timeframe and within available budgets. Implementation projects are often delayed because planners make the implementation schedule without considering indirect factors that might affect the project. Planners often fail to foresee that implementation can get affected due to the size of the software, location where it is being implemented, internal politics, authority, and governance.

Employing Six Sigma concepts in preparing schedule estimations will help planners to effectively include all these factors which may indirectly affect software implementation projects. Based on the past records of the client, Six Sigma statistical tools will generate an efficiency chart, which provides details about all types of problems faced with the client during software implementation projects. The chart displays the time taken to resolve such problems and techniques that were employed to solve such problems.

The chart also displays any additional time or costs that went into the completion of the project. Planners can use the information given in the chart for giving due consideration to all the indirect factors that can affect software implementations. This will help in generating true schedule estimates, necessary for the success of software implementation projects.

Tony Jacowski is a quality analyst for The MBA Journal. Aveta Solutions Six Sigma Online offers online six sigma training and certification classes for lean six sigma, black belts, green belts, and yellow belts.

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later

One of the key success factors in an ERP, CRM, or other implementation is that there is good project management. This article touches on some of the features of managing the project: managing Tasks and managing Resources.

The Importance of Assigning Tasks and Resources in Project Management
John Reynolds

There are two major ways to estimate the lengths (i.e., durations) of tasks. The simplest way is to estimate the elapsed time of a task.

If someone says it will take him a week to do a particular task, he is probably offering an elapsed-time estimate. They generally mean that it will take him one work week to get a task done, not that it will take them 40 hours. When estimating elapsed time, people generally account for not working on the project tasks full-time, and for working on other, higher-priority tasks first.

In most projects, however, lengths should be estimated based on the amount of work, not the amount of time. That way, adding resources will shorten a task, and using resources only part-time will lengthen a task. Tasks that fluctuate like this depending on the resources assigned are called resource-constrained tasks.

There are several ways to estimate the resource time for a task. One is to let the project manager calculate the estimates based on an employees performance on similar tasks. Another is to let the employees performing the tasks calculate their estimates, generally based on how they performed on similar tasks. A third way to estimate is to use standard metrics for generic tasks.

Although many project managers like to follow the standards established by these generic metrics, their plans are generally more accurate when they and their employees do their own estimating. It usually takes three to five projects to become proficient, but the eventual accuracy is worth the delay. Sometimes tasks will not be resource-constrained and can be estimated based on the elapsed times. Examples would be training classes or project meetings. Even though two or more people may attend a class or meeting, the length of the task does not shorten. These types of tasks are called time-constrained.

If estimates are being provided from standard metrics or project managers, them resources (i.e., employees) should be assigned after task lengths are determined. If estimates are coming from the employees performing the tasks, obviously these steps will be reversed. Regardless of the order of these two steps, one or more employees should be picked for each task that is resource-constrained.

Employees assigned to multiple tasks are often scheduled for too much work while there are simultaneous tasks to complete and not enough work when there are no task assignments. To maintain a consistent workload, resources need to be ‘leveled.’ There are only two main ways to level resource allocations: by adjusting the task schedule or adjusting the resource assignments. Project management packages generally adjust the schedule to increase the amount of time it takes to finish the project.

Remember these basic principles for assigning task lengths and resources to improve your management proficiency.

John Reynolds has been a practicing project manager for nearly 20 years and is the editor of an informational website rating project management software products. For more information on project management and project management software, visit Project Management Software Web.

• del.icio.us
• digg this
• Recommend on Facebook
• Buzz it up
• Buzz it up
• Share on Linkedin
• Mixx it up
• rddit this
• Stumble Upon
• Tumblr it
• Tweet This
• Subscribe to the comments on this post
• Tell a friend
• Print for later