Top ten Information Security issues to tackle now

Dan Morrill (Security Project Manager) Posted 11

/26/2007
Comments (2) | Trackbacks (0)

Top 10 lists generally help summarize things that people should be doing, or put in context issues and ideas that are going into a nicely bulletized set of things that a company can be doing to beef up their information security program or projects.

Unfortunately, with changes in the ways that companies are being managed, via Software, Hardware, Web 2.0, wikis, blogs, and other ways that businesses are adopting to the changing user landscape that business needs to adjust to. Balancing the legitimate needs of regulation such as SOX and HIPAA against business requirements means that the information security department needs to be flexible in addressing legitimate business and legal needs.

Get an Evangelist - find a diplomat that will help liaison between Business, Legal and IT. The only job this person should do is helping bridge the gaps between the three groups for understanding, ability, concepts, and language. This person is the most important person that can be hired today to help the company work with the ramifications of business decisions, legal requirements, and IT's ability to execute.

Train IT - one of the top 7 reasons that a project fails in IT is because the IT department is not trained to deal with the new technology. If you can't train, hire for particular skills for new projects. If the company is developing an internal wiki, hire a wiki guru. If your employees blog, hire a person to oversee the effort and help new internal bloggers. Have someone who understands the setup, running, and maintenance of the blogging systems or wiki systems.

Decide on a minimum set of qualifications for a position - consistency in Job Descriptions is important, if social skills are mandatory for a position, make sure that those expectations are well described in the Job Description. If they are nice to have that is one thing, but if they are mandatory, then the behavioral expectations should be discussed on interview, with a clean approved way of determining the right personality type for the job.

Take a risk - all IT is risky to some point or another, determine what is and what is not acceptable risk when it comes to an IT project, develop a risk matrix, and use it.

Determine what skills are needed 2 years and 5 years down the road - while it is generally hard to predict where the company is going, there should be a group of IT folks that track and trend new technology and new business ideas. Develop a group that will help set out a minimum skill set for people who are coming in to the company years down the road. Have them work with Training, the Executive Staff, and Business staff to work out a suitable long range plan and have it approved by the senior executives. Using Gartner's magic quadrant can help work out where technology is going, and what skills will be needed. Then train or hire accordingly.

Start Google hacking your company - do this on the same schedule you would do for any other form of audit. Add to that blogs, wikis, and other sources of data that go beyond the traditional Google hack. Odds are most likely initially you will be very surprised at what you will find out about your company.

Develop a defense in depth program for the company - insiders, outsiders, and general policy avoidance have lead to some of the biggest hacks of 2007. Start a plan, make it happen, fund it within reason; use the risk management table to help determine what the greatest threats to the company are. Listen to your IT department; they know where the bodies are buried. If they have nothing to add, or your security department has no idea what to start with, time to reevaluate the security department and their effectiveness.

Reevaluate everything - risks, trends, and times change, how old is the backup plan, the risk management plan, do they reflect where the company is, and where they are going? Or do the plans exist as a snapshot of the company two years ago.

Learn Web 2.0 and Web 3.0 - the massive changes brought about by social bookmarking, social networks, blogs, wikis, and other data points have altered the nature of information security. It has fundamentally altered how people and companies need to address security issues. While the attack vectors might be the same, the data in them, the way that people are socially engineered, and how they talk about where they work has altered. This change is permanent; there is no way to go back, start planning on data security around these kinds of technologies now.

Teach your users - the internet is not a fun happy safe place in which to work, play and shop. It is a cesspool, but one that we need to do our jobs now. Teach users to be defensive, just like you teach defensive driving, self protection, and due care. Users are still the weakest link in any security program, time to take them in hand and work out easy digestible brown bag lunches to talk about all the things that are happening now.

If a company can do all these things, and work out the processes so that the company can be proactive, they might actually stand a chance in staying on top of things. Some of these positions need to be hired for, and need to be diplomats, technicians and evangelists to make some of these changes happen. Others in this list just require that companies stay on top of the shifting changes in technology, policy and people issues. All of this needs to be managed against acceptable risk as the company sees it. Starting fresh in 2008 might make 2008 a safer year for everyone.

ERP for all ?

alokechakravartty writes:

12/6/2007 #

I consider this comment made without much thought. Need for ERP was there even when we used to implement manual systems. The computer software is just a tool. The need for integrated system will always be there and will grow as long as there is growth in industry. In future also there will be requirement for control, connectivity and visibility which is possible if only there is a solution like computer software being offered now. Nature of computing may change but basic requirement will remain.

The main problem is that ERP is dominated by IT professional where as it should be dominated by people having business experience and knowledge.

The operating people know what they require and how the IT professional will have to understand or fallow what the consumers actually need then only that ERP will get accepted by all the companies. Most of the ERPs fail at post implementation and on implementation stage.

ERPs will have to be easy to handle and the user should be able to customise it they way they want. The manufactures of ERP should just make the basic structure and all customer specific requirements should be customised by the user. I think this change in coming sooner the ERP manufactures acknowledge it better it will be. Days of standardisation are over. No company or organisation can be cloned. Every organisation is different hiving different style of operation. Regulations also vary from county to country to country and region to region which is difficult to incorporate in one single product.

ERP keeps an organisation tight. One has to also look at the cost of ERP. In the world the percentage of small and medium companies are more and they can not afford large ERP solutions. Most expensive part is the implementation cost. I think if this part is transferred to the customer/user by giving them more training will give accelerated growth to ERP.

I do not think ERP has yet gone down below the elite level yet but need of the hour is to make it affordable for all .

Dr.Aloke Chakravartty
Dean -TIG Business Schools, Calcutta, India

Alternative ERP Implementation Strategies: What's the Best Approach?

Alternative ERP Implementation Strategies: What's the Best Approach?

Eric Kimberling (ERP and Business Consultant)

Last week, we cited an industry article about alternative ways of implementing ERP systems. The article gives an example of a large ERP implementation that challenged the traditional notion of going live via a "hard" cutover at go-live. Instead, the profiled organization stuck to strict deadlines, went live on time, and made changes to the system as needed going forward to address any functionality gaps that were missing at the initial go-live.

In some ways, a more iterative approach to ERP software design, development, and go-live is a refreshing change from the typical project that misses duration and budget milestones. However, there are three significant risks to this approach:

1. Organizational Change Issues. First, this approach creates organizational change management issues. On the one hand, this approach helps create buy-in and ownership of the new system. However, ERP change is significant enough as it is, so going live without having worked through at least the major issues can be disruptive and demoralizing to the average employee. In addition, users become very frustrated when their system changes from week to week due to new enhancements or updates to the system.

2. Business Risk. The organization that was profiled was an educational institution, and the ERP focus was on financial functionality. The article notes that there were problems processing paychecks as a result of going live without hashing out all the kinks. One could argue that a few missed paychecks aren't too big of a deal, but the consequences could be much more severe for a manufacturing or distribution company that finds it can only ship a fraction of its normal volume after go-live. If I were the CEO of a manufacturing or distribution company, there is no chance of me being comfortable with this approach given the high level of business risk and uncertainty around this style of implementation.

3. Lack of Clear Requirements and Functionality. There is something to be said for drawing a line in the sand and saying that you won't go-live with the new system until key business requirements and functions are fully developed and tested. Going live without ensuring that key business needs are met and thoroughly tested is risky and irresponsible at best.

4. Difficulty Managing System Changes. The flexibility of ERP makes a more iterative approach more possible; software can constantly be changed as needed to meet evolving business requirements. However, such flexibility can create somewhat of an operational mess if not managed appropriately prior to and after go-live.

So what's the "right" way to implement ERP, assuming there is a right way? The answer is somewhere in between the two spectrums. There's something to be said for both approaches. The traditional "design-build" ERP implementation strategy has some structure that helps minimize risk, but it lacks some of the urgency that the alternative approach affords. The alternative approach, on the other hand, creates a sense of ownership and urgency by ensuring a broad set of employees are working out the kinks in the system, but it also neglects key functionality that should be in place prior to go-live.

The best thing is to try to get the best of both worlds. Clearly defining requirements and making sure the system meets these requirements prior to go-live is critical. At the same time, there is some value to having people start using the system before all the detailed kinks are worked out.

When we at Panorama Consulting advise our clients through ERP implementations, we typically suggest a "soft" go-live with a core group of employees several weeks before the official cutover, which serves as a way to get people comfortable with the system, test the system using real data, and work out kinks along the way. This helps balance managing business risk with creating a sense of ownership among employees, which is critical to an ERP organizational change management program.

Panorama Consulting Group Home Page

CEO Geeks Rule

Dan Morrill (Security Project Manager)

If you ever doubted it, then you need to go over to the Business Week article that talks about the early integration of IT in business, and how CEO's who get it, who label themselves as computer geeks get their businesses growing faster than folks who do not.

While companies have many strategies to make them grow, in many of the companies that we have seen, IT is still off in its own corner, and not really integrated into the business. Business asks for things, IT says no, security says no, rather than try to make some kind of process where the decision is about risk management, rather than simply no.

Yes-73% of the "total geeks" reported double-digit average annual growth in their businesses over the past five years. Close to half-48%-of "total geeks" also reported that their businesses reached the 100-employee milestone within five years of launch, compared to one-third of all survey respondents.
We also found it was important to integrate IT into a company's business strategy early. The survey found that, while 98% of respondents said their company had a defined IT strategy as a small business, those who viewed IT as a "strategic or competitive resource" tended to grow faster than CEOs who said they "spent just enough" to ensure that employees could do their jobs. Plus, 18% of respondents said that "not integrating technology into our business strategy sooner" was their biggest IT mistake over the years. Source: Business Week

Many management articles will always say that people need to keep IT in the business, and that business should be an active participant in IT, and IT should be an active participant in business. The ability to do so it widely debated, but has a simple outcome. If you want to have a better company, IT is a base resource, that must be leveraged to make better decisions, grow the company faster, and generally support the business.

There are few real studies that back up this assertion, so the new one quoted by business week should be on every manager's desk this morning. Especially if the IT department is estranged from the company. Something to think about, grow faster by incorporating IT better, or grow slower by letting IT be on its own in some small dark corner of the company.

Whether your company is ready for ERP ?

Check out whether your company is ready for ERP .

ERP Dead

Whether ERP dead ?

Click this for the answer

Many reasons why Microsoft is Not Doomed

Many reasons why Microsoft is Not Doomed

Dan Morrill (Security Project Manager)

We are not Microsoft fanboys, nor are we Linux fanboys, so there is no particular stake here at all, yet we just have to rebut the idea of "7 reasons Microsoft is doomed", and look at the Channel 9 answers on the "7 reasons Microsoft is not doomed".

We all love to hate the big lad on the street, and there is no doubt that Microsoft has its issues just like any other big company, pick one at random, IBM (who was going to die in the 1980's), Sun (who was going to die in 2000), Yahoo (who is supposed to die this year), Coke (who is always going to die because Pepsi is cleaning their clocks), Nintendo (because their new box was not hard core enough, we are sure there are people laughing at that one), Sony (because the PS3 is in 3rd place and they love root kits), there are a million ways that a company can die, and there are a million groups that will secretly rejoice in their death.

This is why we have the techcrunch dead pool

Microsoft is not about to join them any time soon, yes they are big, yes they are increasingly slow to respond, yes they make mistakes, and yes they seem arbitrary and capricious at times. This is just the lay of the land in a big company. Companies need to take risk, Xbox, Zune, surface, IIS, yes they are all risks, but they also have their fans and adherents. Yes the products could be better, and yes apache still wins in the web server market, but they also don't own the whole market, there is room for more than one player.

They might have only a couple of cash cows, but they have more than one, and they still have a lot of cash, and like all good companies see the need to experiment and take risk to make more cash cows. No one can fault Microsoft for the level of experimentation they are willing to go to. When the surface computer debuted, many people wanted it, and wanted it in a tablet or PC format. It will probably happen, because risk is good, change happens, and Microsoft still thrives on change.

Most blue chip companies get to a point where their stock stays static; the stability of the stock price goes along with a certain girth of company, and frankly a certain age of company. While it would be great to harkens back to a smaller more nimble Microsoft where their stock split and growth was at double digits, you don't and cannot get that kind of growth in a multi billion dollar company, economics does not work that way.

Dell, HP, and others are struggling, they are in trouble in many ways, as margins get razor thin on computers, they need to sell more to make up in volume for what they are not making on each PC. This is the reality of the commodity market; commodity goods never have great margins. Vista is just one way to sell a PC, so is XP, so is Ubuntu, they have to sell lots to make money, they are also going to experiment to see what sells.

Realistically it is far too easy to poke holes in the argument presented by Geeks and Technology, we recommend more college, some real look at economics of the computer industry, and a better understanding of the computer industry around them.

Whether ERP Needed for you ?

michael.panosh writes:

8/31/2007 #

As a successful ERP vendor we continually come across the issues raised by Eric, especially in our so called mid-market or SME customers. Interestingly, there are a few consistent reflections shared by many managers and business owners during our discussions that we have collated into a 'things to think about' list.

First up, as Eric states, the most important question is "What business problem are you trying to solve?" Unless you know this any effort - ERP or DIY - is doomed from the start. So consider:

* Can your company pinpoint and cost the Top Five business issues?
* How do you know the business will be more effective with an ERP solution?
* Are your competitors doing this?
* Can you grow business profitability using your current tools and methods?

As you answer these questions you will be better placed to talk to ERP vendors. But to reiterate, understanding the business problem is critical, as ERP vendors cannot easily implement an effective solution if the objective is unclear.

Fortunately, vendors can be the best resource to determine your business problems, as their staff should be intimate with the challenges of your industry. Presentations by their presales staff will typically declare broad industry issues then drill into details of specific issues relevant to you. In many cases these may surprise you, as the vendor will speak to as many people in your company as possible to uncover examples of where their system can add significant value. The best part is that vendors usually do this for free as part of their opportunity qualification, potentially saving you from hiring consultants to discover and document basic business issues and limitations.

Expect this process to be iterative - you will learn things about ERP that you can use to ask better questions about ERP.

And while there is no magic bullet solution that is applicable to all companies, there are a number of common aspects of an ERP system and the implementation team that you should consider:

Functionality: Functionality is the heartbeat of an ERP vendor's product. It will drive your competitive advantage so ensure that the solution has all of the functionality you need to trade right now, plus the features you would love to implement if you ever had the time.

Of course, you need to trade off practicality here as well. For example, think very carefully about any solution that requires more than about 30% customisation - having to write custom functionality for you adds complexity and cost and will make upgrades more difficult. And negotiate extra hard if the vendor is offering you some kind of "R&D rebate" where you become the test case for functionality that they actually want to put in their product. Make no mistake, agreeing to this may seem OK at the time, but you are a guinea pig with all the risk and effort that entails (and put a rider in the contract to ensure you are well compensated should they bail out of the project part way through because it is not working out as they expected).

Flexible and Integrated: The solution should be modular so that you can build it up over time, but fully integrated so all modules communicate with each other. That way you can be assured the system can at least deliver on the promise of faster access to business information and streamlined business processes. It should also cater for your business processes without breaking the underlying functionality.

While vendors will promote how they can implement industry best practice, as Eric notes you need to maintain your competitive edge - there is no benefit in adopting your competitors' business model if you currently beat them by being innovative in the way you trade.

In particular, be wary of larger ERP vendors who want to sell you an "industry template" version of their software. These templates seem to be great value as they are usually presented as a cost-effective option that will streamline the implementation process and reduce the risk to your business. However, such templates are typically based on the way their large enterprise customers work, not how SME companies operate and play to the needs of the vendor not you as a customer.

Indeed, in an interview with Datamation, Frank Gens, Senior Vice Ppresident at research firm IDC, made the observation that the large IT vendors attempting to penetrate the SME market "will need to shift more than the size of the products...they’ll need to transform their corporate culture."

As Gens notes, "The business model for those [big] companies traditionally is a relatively small number of very big deals. And to now change your approach, and your operations, and your strategies, is quite a culture shift and a business shift. We’ll see how they do."

He concludes that "History has shown that it’s much easier for the small guys to scale up than for the large guys to scale down."

In a similar vein, be wary of "best practice" templates from large vendors - these work well for highly rigid, fully repeatable legislative or industry compliance issues - such as tax reporting or electronic trading catalogues - but not so well for SME customers who don't tend to trip over the compliance threshold in a big way.

Single Source: Ideally, all aspects of the solution should be handled by the vendor - many SME solutions are presented as "integrated" but you are actually buying modules from various third parties that are bolted together by the service provider. Retail Point-of-Sale is often sold this way, with a core finance and inventory management system connected - often by an end-of-day batch process - to a standalone POS. Be very wary of this type of solution, as your risk of support issues increases as the number of suppliers to the solution increases.

Vendor Credentials: There has been considerable consolidation in the ERP market over the last few years, and the mergers and acquisitions show no sign of abating. Ask any prospective vendors for contact details of at least three customers who have been installed for more than two years in your industry, then use the web to find some customers they didn't tell you about and contact them.

Request the vendor's financial information and ask whether there are any legal actions outstanding against them. If you have access to a ratings firm like Dunn and Bradstreet, use that service to gain an understanding of the vendor's credit worthiness. And don't be worried if the vendors you consider are not household names. Typically, the vendors who focus on SME do not have the marketing budgets required for general advertising, so talk to your peers and industry associations. The ideal vendor is highly likely to be a smaller, local player with deep expertise in your industry and a history of servicing SME customers.

Support: The vendor's professional services team will be very keen to provide 'feet on the ground' support, where their consultants work with your team to optimise the ERP software, provide training and/or help recover if things go wrong (and it's not just software bugs that cause things to go wrong. Your staff can unwittingly cause chaos if they poke around the database or change administration settings on the fly). Ensure that the vendor charges local rates for these consultants, and unless you are outside a major city, do not agree to pay airfares or accommodation for their 'experts', as the cost of travel is their business expense, not yours.

Telephone, email or web support for general queries is commonly bundled into a support contract, and will likely require that you nominate a limited number of staff who can call the vendor for help. Don't be surprised if the contract limits the number of incidents per month or number of hours of telephone support. Finally, the vendor help desk is rarely a cost-effective training method, so vendors will push back if they feel your staff are taking advantage of the support team to wrangle free consulting.

Finally, ask how the vendor will plan and support software changes that better reflect your business needs. You are unlikely to convince an international vendor to update their core code, but smaller domestic vendors can be more easily influenced, especially if they see that the feature can help drive more sales.

Implementation Expertise: Industry scuttlebutt has it that many large implementations have been undertaken by the 'Happy Bus' method where a few experienced (and expensive) team leaders manage a large group of much less experienced (yet strangely, not much less expensive) juniors.

While this is less likely with SME projects, ask to see CVs during the sales process and match those up to the people actually doing the job. Ensure that you are not paying for vendor staff who are training on-the-job, and if you are in any doubt about the skills of the people doing the work, discuss it with the vendor straight away so your concerns can be addressed before the project is completed.

Investment Cost: While your aim should be as inexpensive a project as possible, budget at least one percent of your revenue as a good ballpark for the total project cost when comparing vendor proposals.

For SME projects, the software cost, new hardware/database and implementation services are likely to be each one-third of the total price. Software maintenance and/or ongoing support are typically separate line items that usually range from 15% - 20% of the licence cost. Make sure that proposals cover all the items you discussed with the sales team, and where you decide to delete an item to save cost - such as using your staff to migrate data from your existing system - ensure that the vendor provides some form of written project impact statement so that the implications arising from deleting the item are clear.

And while asking for Return on Investment (ROI) figures is the norm, the reality is that few projects capture the requisite before and after baseline details that provide a definitive ROI. You are better off asking reference customers how the system changed their business practices than studying vendor-written ROI papers.

Solution Type: There is a perennial argument in business circles that advocates either best-of-breed or fully integrated. With best-of-breed you buy specialist products for each business function and bolt them together to build a complete solution. Fully integrated products are typically not as feature-rich in any single area as best-of-breed, but they come from the same supplier and so notionally have a lower purchase cost and overall support cost.

SMEs should approach a best-of-breed project with healthy scepticism, as you will rarely have the skills, time and money required to connect the products together and maintain stability in the face of changing business processes, industry requirements and customer demands.

Note that it is OK to customise a small percentage of your solution to implement your competitive edge, but stay focused on getting that done, don't let scope creep and "hey, what a great idea" pad the wallet of your vendor's professional services team.

Upgrade Path: Before you pay for software maintenance, ask the vendor reference accounts about their experiences upgrading the product. While very few upgrades are painless, you need to know whether the vendor provides value for the maintenance charge (i.e. does the functionality included each year add value to the business?) and whether a team of consultants are required at extra cost to actually do the upgrade each year.

Technology: While there is no doubt that technology can streamline your business process, help retain customers and improve profitability, technology for its own sake is a waste of your money. It is also an area where vendors can use smoke and mirrors to hide inelegant products features...or suggest that the next release is a Golden Bullet tailor made for your business.

In particular, make sure that the vendor is not offering you a product today that they know will be upgraded to a different product in the future. For example, one large international ERP vendor - perhaps more used to consumer software products than business critical implementations - has FOUR versions of their product (actually four different applications from four different acquisitions) that they brand under the same general name. If your business grows then it's very likely you will have to "upgrade" to a different product, which is essentially a new implementation even though it has the same family name as the product you purchased.

Another large international vendor - who has considerable database expertise and should know better - is planning on upgrading customers to "new technology" at some point in the future. Access to this new technology may be included in your Maintenance cost, but once again, it is basically a new implementation and needs to be considered as such. It is highly unlikely that all the features you have already paid for will be in this "new technology" version, at least in the first release.

And a specific comment on Eric's note that "Many ERP systems use proprietary development tools". Yes they do and there are good historical and business reasons for that. But at the end of the day, the cost is not in the proprietary development tools but in the training time bringing staff up to speed on what all those millions of lines of ERP code actually do. And that's the case whether it's .NET, C#, Java, ABAP, C/SIDE, X++ or the myriad of other languages used by ERP vendors.

So... the decision to implement ERP represents a major investment that impacts the whole organisation. A well-planned and implemented ERP can change the way you do business and significantly improve profitability, but remember there can be pitfalls if you have not prepared properly. Make sure you do your homework - have a clear objective agreed at the outset, prioritise your expected outcomes and solutions, research potential vendors carefully, ask the right questions for your organisation and be prepared to invest your time. It may take a little longer at the outset but will prove vital to the long-run success of your business.

Single ERP Or Best of Breed?

Single ERP Or Best of Breed?

Eric Kimberling (ERP and Business Consultant)

Although it may sound shocking to some that have jumped on the ERP bandwagon, ERP is not the answer for everyone. In fact, during our ERP software assessment and selection process, it is not uncommon for Panorama Consulting to conclude that ERP is not the right answer for a client.

For some reason, it is easy to get caught up in all the hype and marketing of ERP. Big companies such as SAP and Oracle do a great job of convincing us all that ERP is an absolute must for companies of all sizes and industries. However, that's just not the case.

First, it is important to remember that there are other options out there. ERP in the traditional sense means implementing a single system to handle all critical business functions. But some companies instead find that implementing and integrating niche packages that handle specific functions extremely well are more suited for their organizations. Others find that their business and operating models are so unique that a completely custom solution is a feasible option. With open platforms such as .NET and WebSphere very pervasive these days, custom solutions aren't as crazy of an idea as they were 5 or 10 years ago.

So how is one to decide? What are the tradeoffs? In general, there are three key considerations that should help you guide your decision:

1. Business Risk. This is probably the most important. ERP is risky from a business perspective because its functionality may not meet the requirements of your business. Custom or best of breed solutions are risky from a technical perspective because, if not managed properly, the cost and time associated with developing a system from scratch can quickly spiral out of control.

2. Technical Competency. Many ERP systems use proprietary development tools, which means that you as a company will have to rely solely on the vendor and/or you will have to hire employees with very specialized skill sets to maintain and modify the software going forward. On the other hand, if you go with a custom or best of breed solution, you may have to beef up your IT staff with people that know .NET, integration, etc. In either scenario, most companies require more technical staff and resources after they implement new software.

3. Business Processes. This one is easy to overlook. During the evaluation and selection process for new software, it is important to identify and prioritize which business processes are the most important to your success and competitive advantage. Those are generally the ones that you don't want to break and want to continue to find ways to improve. It is in these areas that you want to be much more discriminating in terms of what software will meet your needs. Many companies have spent years developing and tweaking their business processes to give them a competitive advantage, so it is important not to give this up just because you are implementing new software.

While the above three areas do not suggest that any option is better than the other, they do provide a few starting criteria to use when determining which direction you want to go with your organization. In many cases, companies find that one particular ERP package will meet all their key requirements. In others, they find that after evaluating their ERP options, their needs will be better suited with a custom or best of breed solution. In either case, what's important is that companies carefully consider their options and scenarios as part of their overall IT assessment and selection process.

Proving ROI on ERP solutions

From www.itshowcase.co.uk

Proving ROI on ERP solutions Dave Worsman, Operations Director of Ochiba Business Solutions, a dedicated SAP Business Partner specialising in the delivery of SAP Business One to the SME marketplace, shares his experiences Having worked with so many businesses over the last 20 years that have undertaken projects without a proven business case, it's good to see the tide has well and truly changed. Now projects are forced to have that all important definition of goals aligned to business benefit and that does make for easier, quicker, and ultimately cheaper implementations. This is of great interest to us as specialists in SAP Business One for small to medium enterprises. The case for justification is just as significant for a 4 user system as it is for a 400 user system, and we need to be able to help both extremes prove their potential ROI. At Ochiba we have been working closely with SAP UK and with Martin Southern at Shark Finesse Limited (specialists in ROI software) in order to drive business case justifications for ERP and other software solutions. This has taken us deeper into the world of 'the business cases for ERP' than anyone else I know. Shark are specialists in this field, and it isn't for the highest £'s value of business cases ever written, or their complexity, but certainly for sheer range of experiences then I believe they are hard to beat and we can all learn from that. So relax...this isn't an advertorial...and we will now share with you some real life experiences of business cases and provide a light hearted insight into the murky world of ROI (Return On Investment) and business case justification for ERP installations. Not interested in this subject ?...Well, bury your head in the sand at your peril...because like everything else in life, there are always lessons to be learned...and no-one knows it all. What is ROI ? Businesses exist to generate profits, fulfil the planned objectives and to an extent serve the community at large. Good business decisions are essential to protect long term business strength and ensure benefits for everyone. But what constitutes a good business decision and how can these be determined from an economic perspective? Let's get in the mood with a simple example... Assume your mobile phone bills are £100 per month and a rival operator offers the same service for £70 - if there truly was no difference in the service everyone would look to ways to cut the costs. This is pretty obvious. However, what if the new operator charged £200 to transfer to the new service - how many people would consider this a good deal? There are a number of technology, service, and coverage questions, but the hard headed business decision is: "Am I prepared to spend £200 now to reduce my bills by £30 per month?" This is exactly the same scenario that many businesses face when examining whether to invest in ERP solutions for their business. They already have solutions that work, are producing profits, altogether successful - so why do they need something new that's going to cost money at this point in time? Traditionally, these discussions have been based around features of a solution rather than its economic impact on the company. That's because everyone can understand the technical terms, but quantifying what it will do for the business P&L, and proving that the large up front cost is justifiable - now that's scary ! To find these economic benefits, we need to turn our minds to the language of savings that are understood by our financial friends, because it's those hard £s that are going to justify the investment spend required. Try some of the terminology around improvements in invoicing, for example: The Technical message - Economics meaning - Electronic invoicing = Avoid postage, stationery costs, manual time Auto posting to customer ledger = Faster invoice approval and payment Avoid manual input = Fewer errors, fewer concessions and faster cash If we can find these economic savings, then we can prove that the additional up front investment is more than covered by the benefits that will be generated. Always remember that the "do nothing" decision is available at all times, but if we can prove the benefits are good enough, then everyone will be happy to move forward on the economics as well as the technical aspects of the solution being reviewed. What measures do finance people use to assess what is a good return? There are 3 of them: Payback - At what point in time will the economic benefits recover the original costs? In the mobile phone scenario above it is 6.7 months, being £200 up front cost divided by the £30 per month savings. The answer is a time saving. But now you ask: "What happens after the 6.7 months period?" The decision just gets better, so how do we find the annual percentage return on the £200 just like we would be quoted an APR% on a loan - we can all understand that. IRR or Internal Rate Of Return - the percentage rate of return on the incremental spend, over a selected time period, by comparing all the benefits with the original cost. OK, now I get it, but let's say that I am borrowing money at 6% to fund my extra spend, what profit do I make over time, using a cost of money, and turning this into a £s value? A sort of increase in shareholders worth. This is... NPV or Net Present Value - a £s profit in today's terms, comparing costs out, savings in, and an annual cost of money. So, now that I have all three measures, if I could identify solution benefits, I can deliver a full ROI based business case for my technical proposal. Let's see this in action... A department store proposes to spend £250,000 on an ERP solution. The owners agree that benefits will accrue from reduced queuing time (1 in 12 people waiting would previously have left the queue), reduced stockholding and better buying margins. Benefits totalled £18k per month, but supplier would charge an extra £2k per month for the service. Over a 36 month review period and a 10% cost of money ...is this a good deal? Who can possibly tell unless we look at the 3 key economic measures: Payback 16 months (OK....but not that exciting) IRR 89% per annum (fantastic) NPV £249,000 (increased shareholder values) It's now plain to see this makes sense and the technical decision is now supported by the financial language that business people understand.

Case study examples Our experience tells us that business cases (economic justifications) pivot on the identification of benefits inside organisations. Sometimes these are hiding away as internal inefficiencies long ago forgotten about by the business - and are talked about as just something that never quite got "fixed". Some of these caused major business pain though....Here's a sample of what we found on our own travels: "What about stationery" Sometimes being an expert is a bad thing....you tend to miss the most obvious savings, because your own expertise and ego makes you look for the difficult issues. A £100 Million distributor of paper and stationery was considering a new ERP implementation. The benefits discussion had found the obvious savings - some inventory, some time savings - when someone in the room said: "what about the stationery that we use for delivery notes?" A chortle went around the room. "Don't be silly, we'll still need to print the things" and the contributor went quiet. 10 minutes later he said again: "what about stationery?" And the audience became intrigued. He then went on the explain that the current delivery notes were printed on a non standard size paper and had a peculiar print layout that only one company could supply. The new ERP solution could print straight onto A4 at virtually no cost. "How much do we spend on this funny paper at the moment?" "£21,000 every year, over 3 years this would save £60,000 and tip the whole project into positive returns." Moral of the story....never ignore a benefit just because it sounds simple The supplier didn't major on the feature of printing straight onto A4, but this is where the biggest financial benefit actually existed. "This project just can't be justified" Both client and sales account teams are often concerned that starting an exercise to discover economic benefits could actually backfire if there were insufficient benefits for the business case to be justified. It's actually very uncommon, but sometimes you need to look in the most unlikely places. A car rental company had grown so quickly it needed better ERP systems to manage its business. The sales team managed to get the IT Director and the Finance Director in a room specifically with the objective to discover reasonable benefits that could arise. We looked everywhere - all through the finance dept, the IT budget and we could only find savings to cover about half of the project cost. We thought we had exhausted everything and stopped for lunch. The Operations Director joined us and casually asked: "how's it going....we all know we need new systems". He then said: "on the new unified ERP system, will it track all the mileages of the vehicles that we have ?" "Of course" we replied, "why do you ask?" "Well I can get the vehicles serviced at the proper intervals rather than overrunning the mileage and incurring penalties." "What penalties?" someone asked. "Oh, the £165,000 per annum from the suppliers who charge penalties if we don't service the vehicles properly - we wouldn't pay that if we had accurate mileages." One argument supported the whole business case. "We don't have any IT at the moment" Imagine a business that had grown successfully to a significant size without ANY major computerised ERP systems. This is much more common that you think. A food business employed over 200 people and was hugely profitable without any major IT infrastructure. This gives major opportunities for improvement, but also an in-built resistance to spend: "Why do we need IT...we are successful without it ?" I attended a meeting to examine the economic benefits, and they were everywhere. Excitedly we began firing benefit after benefit to the client - it was too easy. However, in the middle of this I became disturbed as to the impact that we were having on the client. Our own incredulity about how this business had grown without IT had started to become a little offensive. We stopped the conversation and apologised. We started again with a whole new emphasis about building upon what they were already doing and explaining what could be possible in service, customer improvements AND supporting them with the benefits. The financials were the easiest I've ever seen and the customer's FD knew this. We just had to be sensitive to their success and emphasise how much more success could follow. Summary Many people are frightened by business cases because it's an area of expertise that has a certain mystery surrounding it. I hope that this article has helped reduce the fear and provide anecdotal evidence that the majority of proposals really do deliver positive ROIs. Ochiba use the tools and business case histories from Shark Finesse Ltd that allow us to engage customers and focus on the real hard benefits that can arise as a result of new ERP solutions. This ROI approach can be completed in a minimum amount of time, does not involve boring / mistrusted spreadsheets, and can make a major difference to the perception of a project inside our customers. Our own business has a mission to simplify this for everyone because making good business decisions and delivering returns are key to the constant improvement in the impact businesses have on the whole community.

Analyzing ERP's success in organizations.

ERP success stories will reveal that they were made possible through deliberate and hard work. The assessment of enterprise planning resource and defense enterprise planning resource are important tasks in this context.

ERP success stories need not necessarily mean that an organization needs to be contended with what they have achieved. They must think of extending the scope of enterprise operations so that many and thereby be a role model for more ERP success stories.

Some of them requiring attention are as follows:

Jada precisions Plastics co INC and IQMS ERP software

The manufacturing Company Jada Precisions Plastics INC was not happy within the initial ERP systems that were established to help them in raising the competence levels. The software definitely helped them to reduce the complexity of the labor but it was not the ultimate answer.

They finally got the much desired results from IQMS ERP software. The software was instrumental in giving the results. Upon analysis it was found that the former ERP systems tried to give ready made solutions to their problems in the form of packaged solutions while the later facilitated tin creating an automatic system for data transfer. This resulted in ERP success.

The point to be learned from this issue is that the ERP vendor should provide appropriate solutions based on the requirements of the client and not on the basis of his services. They are meant to make one understand the critical success factor for ERP implementation.

Eiffel ERP software's implementation in U.S. based chemical company.

In this situation their main challenges of the software lay in facilitating communication between the corporate office and the manufacturing unit that uses very old systems on one hand and managing a new chemical plant. Both these process had to be done simultaneously with the second process coming under the control of the first one after the intervention of ERRP software. Deciding this is like squaring upon critical success factor for ERP systems.

The main challenge with the first issue was that the data processed by the corporate office was to be reverted and resend by the manufacturing setup which was using primitive systems that were not capable of processing large information. The manufacturing unit neither required the whole information nor had the ability to process the same. This was the critical success factor for ERP implementation.

Eiefeel ERP system was designed to filter the required information and storing the rest till the retrieval. In the meanwhile ERP also processed the complex information in order to suit the capability of manufacturing unit.

The issue with the second process was that the newly setup unit had to become a part of the manufacturing unit. The problem was that the new process could work on the latest software whereas it had to be coordinated with the old manufacturing unit. The new software was designed to do the very old process but by making use of the latest equipments and thus ERP success followed. This again points the facts that ERP has to be designed based on the systems in the organization.

WinMan ERP in Athena controls

Success stories usually explain how ERP facilitated organizations to reach milestones. This story has a different style. They explain the concrete steps that are to be taken in an organization in order to attain the maximum benefits from ERP. This company is a concrete example and a living proof to substantiate the fact regarding the steps that a company needs to take and in not believing that a more implementation of ERP will give the necessary impetus for success in the organization.

The basic factor for success in this company is backed by the fact that they believed software to be a tool and not the solution to the enterprise problems. This is backed up by the fact that the company successfully combined the business practices with the nuances of the software. This process took place during a crucial time for the company i/.e. when they experienced a sudden deflation of profits.

They had a successful collaboration with Winmap software to unleash the enterprise Solutions. The cordial work atmosphere among the two prevailed over any mishaps. They experienced an increase in the profits level and various aspects of business like inventory management, cost reduction and so on. The facts and figures were amazing and would not have happened if the company had not used the circumstance like a platform for doing their best and understanding the fundamental mistake of not aligning software with business process.

Intitutive ERP Software in San Antonio's Lighthouse

SanAntonio's Lighthouse is a company that provides employment opportunities to the visually challenged and others undergoing some form of physical hazards. The company's core business is to manufacture products that best suit them to carry on a trade or profession of their own choice. In addition to making them the company also sees to that it reaches the end user.

The market trend underwent a sea change. The company decided to change their strategy in order to ensure that the customers received the products in the correct time. The pressure from competitors circle also led them to think an alternative for their existing distribution system.

The company had also ventured into selling goods and services online. They went ahead with Intitutive ERP systems as it gave them advantage of services like Microsoft Environments and platforms. The implementation process and shipping time were drastically improved. The company was able to realize its full potential and sailed in tune with the market demands.

SAP ERP Solutions in TISCO (Tata Iron and steel company Limited)

The steel majors prompt response to market change and shifting to customer orientation from product coupled with the implementation of ERP will speak more than volumes of their success for the timely action. The company is now able to reap benefits in all aspect and make further progress in each and every operation of an enterprise.

The company decided to implement SAP ERP 3 after careful consideration for they matched best with their requirements. In addition the company also forecasted on what would happen to their operations in the future while making this choice .This anticipation helped them to obtain the proper solution at the right point of time. The implementation process took a long span of about a year owing to the volume of operations and the major steps to be taken.

The company never got bogged down by the reported failure rate of ERP implementations especially in bigger units and kept continuing their endeavors with vigor to get the best and make the whole process learning cum experimental one. The net result brought substantial increase in profits. The speed at which they worked (and without even the minutest error) deserves great appreciation and is accorded as one of the main contributing factors for the success.

Cost of ERP software

Below article explains the typical cost of ERP software

ERP software provider from ERP software solution for manufacturing in Malaysia SAP , Peoplesoft , Oracle..... Navision, Skala....... Globalsoft, Karensoft...... When talking about ERP software, most Malaysian with some ERP knowledge will come across the above ERP provider. The first 3 company, we normally position them as "tier 1", then the next 2 is "tier 2" and the last 2 is "tier 3" ( of course there are many providers in market for tier 1, 2 and 3, the above named companies are just an example) What does it mean ? well , tier 1 , 2 and 3 is the service scope and different market segmentation they serve. For "tier 1" provider, they normally target on Multi Nationals Corporation (MNC) with the budget of millions dollars, and "tier 2" provider target on listed companies and large organization with the budget of less than a million, and "tier 3" provider target on Small and Medium Industries (SMI, mostly manufacuturers) with the budget of less than RM 200,000. (USD 55,555.00) Does it mean that SMI can only find "tier 3" for their ERP solution ? Wrong. If you aware of the trends in Business and I.T, This rule has been changed because some big players like SAP also starting to tap in to SMI market and introduce the ERP solution that less than RM 200,000. (USD 55,555.00) This could be a good news to SMI because with that budget they can buy a stable, proven and reputable ERP software. Then, what happen to "tier 2 " and "tier 3" providers ? I am regret to know some tier 2 providers are still unaware of the business trends, they are still concern on finding big corporation with the budget of RM 300,000 to RM 800,000. When I was talking to such providers, they normally say " SMI ? They got budget or not ? If got more that RM 300,000 (USD 83,333.00)then could be considered........" They don't know the other side is saying : " Tier 2 provider? They can lower the price or not ? If they can lower the price to below RM 200,000, (USD 55,555.00) then I will be glad to find one" - from the SMI Obviously, closing a deal with the budget of RM 300,000 to RM 800,000 is much more profitable compare to closing a deal with the budget of RM 200,000. (USD 55,555.00) Most Tier 2 providers will give many reasons why they do not go to below RM 200,000 ...... For example, company image, less profit, high overhead etc..... then , consider what SAP does, is SAP so stupid to sell its light version of ERP for less than RM 150, 000 (USD 41,660.00)? If the answer is Yes, then why SAP is still the Top ERP provider in the world and capture the most market share ? If the answer is No, then who is stupid ? The "tier 2 provider ?" We are always talking about "long-term business partnership". It sounds good. But when it come to practice, many tier 2 providers just concern on short term profit, and ignore long term benefits. Just imagine, these SMI will keep growing, one day, they may become MNC and listed companies as well, if you are smart enough, target to the right SMI with the potential to grow big , lower the ERP software price for them to use, when they grow, they will ask for more from your ERP software - and eventually, throughout the period, your ERP software price selling to those SMI will sure exceed RM 300,000 and above. and one more important reward - they trust you. For tier 3 provider, they are targeting on SMI with the budget lower than RM 200,000 - sometimes could be RM 100,000 (USD 27,777) . Anywhere , with that price, the SMI also cannot expect too much on features or customization, and could be some bugs in that system. Finding a good tier 3 provider could be a challenge, especially, if you come across the ERP failure under the SMIDEC e-manufacturing grant (now has been changed to loan) , you will know what I mean. However, there are still many good tier 3 ERP provider in the market, the only thing is the SMI need to be careful on selecting the right ERP provider. If you want to know how to wisely select ERP provider, then send me an email. see my article of how to select ERP software solution for manufacturing article.

What is ERP ?

From erp.manufacturer-supplier.com

Below article explains in brief what is ERP software.

What is ERP software ?

ERP software means Enterprise Resource Planning systems. ERP systems are large computer systems that integrate application programs in accounting (i.e., accounts receivable), sales (i.e., order booking), manufacturing (i.e., product shipping) and the other functions in the firm. This integration is accomplished with through a database shared by all the application programs.

When you first see an ERP program, the application programs are similar to those with which you are already familiar. So the production scheduling, billing a customer, processing a payroll and other tasks are done in ways that should be pretty familiar to those of you who have worked with these applications over the years. So what is the big deal? Integration! ERP systems tie these, usually separate, applications together. When a customer service representative takes a sales order it is entered in the common database and in the other applications where it is needed, for example, in the manufacturing backlog, the credit system and the shipping schedule. No more carrying little pieces of paper back and forth. Or writing translation programs to get the information from one function to another. Sounds great, right? Read on!

ERP systems work in real-time, meaning that the exact status of everything is always available. Further, many of these systems are global. Since they can be deployed at sites around the world, they can work in multiple languages and currencies. When they are, you can immediately see, for example, exactly how much of a particular part is on-hand at the warehouse in Japan and what its value is in Yen or Dollars. This is a pretty amazing accomplishment. Sound too good to be true? It is --- all this doesn't come free.

In addition to the technical details, the way the hardware and software are organized, and technically how the logic of the system functions, there is another aspect to understanding ERP. It is the management and implementation issues associated with the systems that may be the most important of all. Whether you are considering the use of ERP, are faced (forced?) with implementation, or are just generally concerned about the management issues involved in using ERP systems, you should understand some of the tradeoffs involved.

We are all concerned about keeping up with new technology and the challenge that this poses. The pervasive promotion and use of ERP systems suggest that, for this technology, we need to understand the scope of these systems and have a basic knowledge of how they work. Fortunately, learning about ERP is not so much learning all-new concepts and ideas, but rather learning about new ways to do things that we already have been doing and the ERP terminology associated with them. This means, whether you are a general manager, information system executive, an accountant, or a student, you already know more about how ERP works than you think you do, but you still need to learn the managerial issues associated with the degree of integration they support.

What are the hidden costs of ERP?

Although different companies will find different land mines in the budgeting process, those who have implemented ERP packages agree that certain costs are more commonly overlooked or underestimated than others. Armed with insights from across the business, ERP pros vote the following areas as most likely to result in budget overrun.

1. Training - Training is the near-unanimous choice of experienced ERP implementers as the most underestimated budget item. Training expenses are high because workers almost invariably have to learn a new set of processes, not just a new software interface. Worse, outside training companies may not be able to help you. They are focused on telling people how to use software, not on educating people about the particular ways you do business. Prepare to develop a curriculum yourself that identifies and explains the different business processes that will be affected by the ERP system. One enterprising CIO hired staff from a local business school to help him develop and teach the ERP business-training course to employees. Remember that with ERP, finance people will be using the same software as warehouse people and they will both be entering information that affects the other. To do this accurately, they have to have a much broader understanding of how others in the company do their jobs than they did before ERP came along. Ultimately, it will be up to your IT and businesspeople to provide that training. So take whatever you have budgeted for ERP training and double or triple it up front. It will be the best ERP investment you ever make.
   
2. Integration and testing - Testing the links between ERP packages and other corporate software links that have to be built on a case-by-case basis is another often-underestimated cost. A typical manufacturing company may have add-on applications from the major?ae-commerce and supply chain?ato the minor?asales tax computation and bar coding. All require integration links to ERP. If you can buy add-ons from the ERP vendor that are pre-integrated, you're better off. If you need to build the links yourself, expect things to get ugly. As with training, testing ERP integration has to be done from a process-oriented perspective. Veterans recommend that instead of plugging in dummy data and moving it from one application to the next, run a real purchase order through the system, from order entry through shipping and receipt of payment?athe whole order-to-cash banana?apreferably with the participation of the employees who will eventually do those jobs.
   
3. Customization - Add-ons are only the beginning of the integration costs of ERP. Much more costly, and something to be avoided if at all possible, is actual customization of the core ERP software itself. This happens when the ERP software can't handle one of your business processes and you decide to mess with the software to make it do what you want. You're playing with fire. The customizations can affect every module of the ERP system because they are all so tightly linked together. Upgrading the ERP package?ano walk in the park under the best of circumstances?abecomes a nightmare because you'll have to do the customization all over again in the new version. Maybe it will work, maybe it won't. No matter what, the vendor will not be there to support you. You will have to hire extra staffers to do the customization work, and keep them on for good to maintain it.
4. Data conversion - It costs money to move corporate information, such as customer and supplier records, product design data and the like, from old systems to new ERP homes. Although few CIOs will admit it, most data in most legacy systems is of little use. Companies often deny their data is dirty until they actually have to move it to the new client/server setups that popular ERP packages require. Consequently, those companies are more likely to underestimate the cost of the move. But even clean data may demand some overhaul to match process modifications necessitated?aor inspired?aby the ERP implementation.
   
5. Data analysis - Often, the data from the ERP system must be combined with data from external systems for analysis purposes. Users with heavy analysis needs should include the cost of a data warehouse in the ERP budget?aand they should expect to do quite a bit of work to make it run smoothly. Users are in a pickle here: Refreshing all the ERP data every day in a big corporate data warehouse is difficult, and ERP systems do a poor job of indicating which information has changed from day to day, making selective warehouse updates tough. One expensive solution is custom programming. The upshot is that the wise will check all their data analysis needs before signing off on the budget.
   
6. Consultants ad infinitum - When users fail to plan for disengagement, consulting fees run wild. To avoid this, companies should identify objectives for which its consulting partners must aim when training internal staff. Include metrics in the consultants' contract; for example, a specific number of the user company's staff should be able to pass a project-management leadership test?asimilar to what Big Five consultants have to pass to lead an ERP engagement.
   
7. Replacing your best and brightest - It is accepted wisdom that ERP success depends on staffing the project with the best and brightest from the business and IS divisions. The software is too complex and the business changes too dramatic to trust the project to just anyone. The bad news is a company must be prepared to replace many of those people when the project is over. Though the ERP market is not as hot as it once was, consultancies and other companies that have lost their best people will be hounding yours with higher salaries and bonus offers than you can afford?aor that your HR policies permit. Huddle with HR early on to develop a retention bonus program and create new salary strata for ERP veterans. If you let them go, you'll wind up hiring them?aor someone like them?aback as consultants for twice what you paid them in salaries.
   
8. Implementation teams can never stop - Most companies intend to treat their ERP implementation as they would any other software project. Once the software is installed, they figure the team will be scuttled and everyone will go back to his or her day job. But after ERP, you can't go home again. The implementers are too valuable. Because they have worked intimately with ERP, they know more about the sales process than the salespeople and more about the manufacturing process than the manufacturing people. Companies can't afford to send their project people back into the business because there's so much to do after the ERP software is installed. Just writing reports to pull information out of the new ERP system will keep the project team busy for a year at least. And it is in analysis?aand, one hopes, insight?athat companies make their money back on an ERP implementation. Unfortunately, few IS departments plan for the frenzy of post-ERP installation activity, and fewer still build it into their budgets when they start their ERP projects. Many are forced to beg for more money and staff immediately after the go-live date, long before the ERP project has demonstrated any benefit.
9. Waiting for ROI - One of the most misleading legacies of traditional software project management is that the company expects to gain value from the application as soon as it is installed, while the project team expects a break and maybe a pat on the back. Neither expectation applies to ERP. Most of the systems don't reveal their value until after companies have had them running for some time and can concentrate on making improvements in the business processes that are affected by the system. And the project team is not going to be rewarded until their efforts pay off.
   
10. Post-ERP depression - ERP systems often wreak cause havoc in the companies that install them. In a recent Deloitte Consulting survey of 64 Fortune 500 companies, one in four admitted that they suffered a drop in performance when their ERP system went live. The true percentage is undoubtedly much higher. The most common reason for the performance problems is that everything looks and works differently from the way it did before. When people can't do their jobs in the familiar way and haven't yet mastered the new way, they panic, and the business goes into spasms.

ERP System or an ERP Wannabe?

Are You a True ERP System or an ERP Wannabe?

Rebecca Gill
(Vice President)

I am beginning to think there is considerable confusion between true ERP systems and simple software programs. And I have to admit, I take offense when a company refers to their product as an ERP system, when in fact, it appears to be a software package with functionality focused in one or two operational areas.

I realize I'm probably overly sensitive on this subject, but ERP is my career and my livelihood. It consumes both my time and my thoughts. So yes, when I read about software suppliers I've never heard of refer to their new or improved product as the "next ERP" or the "ERP alternative", I get a bit disturbed.

Although there are certainly different tiers of ERP packages, ERP at the core is an enterprise wide system. My company, Technology Group International, is not a tier one product like SAP or Oracle, but we do offer an enterprise wide solution. We are a tier two ERP provider that offers significant functionality and quite honestly we are proud of our product. We've spent over fifteen years developing and supporting one core product - Enterprise 21. On average, my development team has well over eight years in tenure with both my product and my company. They are dedicated people. And thus, I feel compelled to be dedicated to them and defend their honor when I read of new products with limited functionality being labeled as ERP systems.

A true ERP system requires significant development time. It is not something that can emerge instantaneously. It needs to grow and be nurtured. It has millions of lines of code and thousands of screens and tables. My development staff has worked hard creating a product for which we can all be proud. It is a software package that includes functionality not just in accounting, but in all aspects of sales, manufacturing, and the entire supply chain. It reaches across the organization to provide a solution set for a company and not just a departmental fix.

Even though I know my company and my product are far from perfect, I feel confident in our product claims and the image we portray to the buyer. If I say we have ERP software, it is because I believe we have a true ERP system that offers a full solution. As fast as I am to sing our praise, I'm also quick to discuss our weaknesses in a given area or market. But as my husband states, not everyone is as vocal as I am or as open about every subject imaginable.

In response to the ongoing feed of ERP news and announcements, I say buyer beware. If you are considering the purchase of an ERP system, make sure it is a true ERP system and not just an ERP wannabe. Look deep into the functionality it offers, perform scripted demonstrations, and check references. Make sure you are buying a real ERP system and not simply a software application that is clinging to popular technology buzzwords.

Linking Technologies to the Business

|

Linking Technologies to the Business

Craig Borysowich (Chief Technology Tactician)

The applications documented as part of the component inventory are mapped back to the business processes that use them. Prepare an association matrix, mapping the applications to business processes.

When this mapping is completed, there will be several paths from the top of the organization to the lowest level components in the organization, that could be visualized.

Store the Information

Store this information in a repository. As shown in the example above, there is a significant amount of information uncovered by the dependency model. A repository is very beneficial in storing and organizing this information.

If this is a Business Process Engineering (BPE) initiative, store this information in the project repository.

See Also

Assocation Matrix

Business Dependency Modelling

Business Dependency Modelling

Craig Borysowich (Chief Technology Tactician)

Use Business Dependency Modelling to:

· determine the effects of change on other business processes during a Business Process Engineering (BPE) initiative,

· determine the dependency of a business or organization on its suppliers and other external entities (e.g., financial services, telecommunications services),

· determine the risk of exposure to your organization should the business of your suppliers (or other external entities) fail due to business problems such as failure to achieve legislative compliance.

Method

To develop a Business Dependency Model, the business must be thoroughly analyzed. The model is built by linking the technology components to the business components.

Identify the critical success factors for the business

Gather detailed information on hardware and software in use by the organization

Link the technology to the business

Determine the relationships and dependencies in the business

Analyze the dependencies and assess risks

Tips and Hints

A modelling tool is very helpful to complete this analysis. As a minimum requirement, a repository is required to store the information gathered in building the dependency model. Entering the data into a modelling tool allows for a detailed analysis of business scenarios.

Charting Roles & Responsibilities

Charting Roles & Responsibilities

Craig Borysowich (Chief Technology Tactician) Posted 19 hours ago
Comments (0) | Trackbacks (0)

In the Roles and Responsibilities Charts, there are four types of roles defined:

Responsible These are the individuals who perform a task (i.e., the doer). These individuals are responsible for the action within the task (e.g., entry of the data into the system). Responsibility can be shared between several individuals.

Accountable This is the individual who is ultimately accountable for the task. This is the individual who has the power to say yes or no, or has the power to veto an action or decision. Only one Accountable role can be assigned to a task.

Consulted This is the individual who is consulted before a final decision is made or the final action is taken. This is a two-way communication, between the individual who is consulted and the Accountable role.

Informed These are the individuals who need to be informed after a decision has been made or an action has been taken.

List Roles within the Process

Look at all of the roles (or people) involved in the business process under study. List these roles. Give each role/person a functional role title.