Slashdot Mirror
Ask Slashdot: When Is It Better To Modify the ERP vs. Interfacing It?
New submitter yeshuawatso writes I work for one of the largest HVAC manufacturers in the world. We've currently spent millions of dollars investing in an ERP system from Oracle (via a third-party implementor and distributor) that handles most of our global operations, but it's been a great ordeal getting the thing to work for us across SBUs and even departments without having to constantly go back to the third-party, whom have their hands out asking for more money. What we've also discovered is that the ERP system is being used for inputting and retrieving data but not for managing the data. Managing the data is being handled by systems of spreadsheets and access databases wrought with macros to turn them into functional applications. I'm asking you wise and experienced readers on your take if it's a better idea to continue to hire our third-party to convert these applications into the ERP system or hire internal developers to convert these applications to more scalable and practical applications that interface with the ERP (via API of choice)? We have a ton of spare capacity in data centers that formerly housed mainframes and local servers that now mostly run local Exchange and domain servers. We've consolidated these data centers into our co-location in Atlanta but the old data centers are still running, just empty. We definitely have the space to run commodity servers for an OpenStack, Eucalyptus, or some other private/hybrid cloud solution, but would this be counter productive to the goal of standardizing processes. Our CIO wants to dump everything into the ERP (creating a single point of failure to me) but our accountants are having a tough time chewing the additional costs of re-doing every departmental application. What are your experiences with such implementations?
I would hire devs to interface with the ERP. Because when you go to upgrade to the next version [of the ERP], you have a modular thing that you can change pieces of rather than having to pay someone to rewrite the entire thing. If you continue to customize the ERP you're using, you'll be locked in to that specific version and all of its security/stability/functionality problems.
Always fucking expand the first instance of your acronym in your summary. Always.
Many of have absolutely nothing to do with Enterprise resource planning in our day-to-day lives. A lot of us don't care about a strategic business unit. Most slashdotters are in the field of making software, not babbling almost-but-not-quite-meaningless business jargon about software.
When asking a detailed question about your employer, try not to include enough information that you can actually identify the company with a pretty good degree of confidence. If they find out who you are you might get a good rheeming out.
My experience is that by using large vendor systems like Oracle and SAP is just a good way to waste money without getting any benefits. Those systems are in general not very well designed, and the money paid is used for marketing, not application development.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
That's the thing with ERP systems. Most companies only focus on the initial cost of the system, but these large ERP setups like oracle and SAP are really just basic frameworks. The most important aspect is customizing to your business structure/procedures. If you take the time and resources to set it up properly then you can pretty much use them without having to manage a thousand spreadsheets and tribal knowledge that most companies use. The tools are always there... they just need to be configured.
If you use a chain of apps interfacing to the ERP and all of them are critical for the business process to run, you are creating a chain of multiple SPOFs. Surely ERPs are made for limiting the technology diversity, so companies whose business is not IT can use IT limiting its exposure to technology expenditure and risks
Interestingly enough, I know which company you work for and I used to work for them at what used to be the residential headquarters. In truth, you're going to find that, at least from my past experience, they've already made up their minds and anything you bring to the table isn't going to have any attention paid to it until long after something catastrophic fails and leaves you without a backup. What I had wanted to do, and what local staff had always wanted to do, was bring everything back in house on the local data centers so that production never stopped when the outside links went down; we were ignored. I do wish you the best of luck in this endeavor though, i mainly only commented because I know what you're going through first hand.
Everything is porn to somebody.
That said, it's not always practical to in-house everything, so a balance needs to be struck - keep the design and some worker bees in-house and then leverage vendors/contractors to spin up extra bodies for build cycles.
Regarding your single point of failure concern - while valid, a properly designed ERP system with redundancies and load balancing should alleviate the core of that problem. Again, balance needs to be struck, while you want a single place to do all of your ERP functions, it doesn't always make sense to have them in one application that has to be customized to within an inch of it's life in order to do everything it needs to do. This needs to be addressed in the design phase to create logical business units that can sit on separate applications that, ex, communicate with the proverbial mothership via an API
there is your answer. ditch it. quick..
---- Booth was a patriot ----
it's been a great ordeal getting the thing to work for us across SBUs and even departments without having to constantly go back to the third-party, whom have their hands out asking for more money.
who not whom.
I forget which large chain implemented ERP and found they couldn't ship a single product for months on end (3? 9? I forgot) because of troubles implementing this all-new all-singing-and-dancing magical silver bullet piece of software. This happened a few years back and so one'd think it should be well-known in CIO land.
Anyway, why are you asking random strangers for advice? As a CxO it's his job to have done his due diligence and all that. You have your marching orders.
You are looking at this backwards. Start with the business need, not the technology that it's built in. For example, a business need would be to capture business expenses. Rate yourself on your maturity in this area from a process, training, and technology perspective. You might need some training to fill the gaps, because I'm guessing your Oracle system can easily do the expense tracking. Perhaps you need to standardize the process people use across the company. Finally perhaps you have a gap between your standard process and the systems you have put in place. Then, and only then, should you start asking the next questions about the data models, the technology platforms, and finally about the integration layers needed to bring that all together.
Always fucking expand the first instance of your acronym in your summary. Always.
True, I agree that HVAC, ERP, and SBU should have been expanded. But some terms, such as "Hypertext Markup Language", "Motion Picture Experts Group", "Universal Serial Bus", "chief executive officer", "Federal Bureau of Investigation", "Systeme, Anwendungen und Produkte", and even "application programming interface" are probably more recognizable to Slashdot's audience in the abbreviated form.
Ummm, what's ERP?
This is a perfecr example case for considering an enterprise, professional world class Open Source ERP solution like OpenERP, ERP5 or Compierre which will not only allow "user" modifications and configurations to application functionality/ source code/ to suit purchaser's needs and requirements, but will generally work with far better with all other data formats and APIs, and is especially beneficial for evading all the proprietary vendor lock-in and incessant hands-out for more payments as article writer noted. If the company has fairly competent personnel in their technology support department, it would not be climbing Mt. everest to have them acquire programming knowledge and expertise from the FOSS applications developers, at considerably less costs that custom modifications. That is unless the company technologists are extricably tied, by perks,limited training and/or personal incentives to Oracle, Microsoft or other large proprietary software vendors whi derive much of their great profits from just such scenario as described in the article.
It always takes longer and costs more than anyone ever thought possible.
The results are not always what you had in mind
It often ends up in court
You definitely don't want to be around while its happening
This should be on thedailywtf.com instead of here, it has all the ingredients
- Huge IT project
- Complete Mismanagement
- Third party vendors
- Access and spreadsheets
- Duck tape and string
This is what the acronym means for many people who play online games. I just wanted you guys to know so you'll understand the giggles coming from the back of the room at every meeting.
Either way you're screwed! Dealing with a deployment of Oracle on Demand, their hosted "cloud" based solution and it's been a mess from day one! Mostly it has been due to the vendors (Both Oracle and consultant) over promising and under performing on all issues. Things that should be simple - things like printing!!!! are over complicated and a mess. (What I need a seprate Internet route-able IP for each printer even though the printers will not be exposed out to the Internet???? WTF???) Can't interface with our current bill payer system? But we were told it could, see right here on page ... what ... oh it can if you now write middle ware for it at HOW MUCH???? And on it goes. Good thing I retire in 5 years, it might even be a working solution by then.
You don't want dozens of applications that interface with the ERP system. If you do that, when the ERP interface API changes you now have to change dozens of applications. The ultimate result of that is that the ERP system upgrade cost now goes through the roof. 10 years laster, someone is going "You are using version *WHAT* ?!?!?! It only works with Internet Explorer version *WHAT*?!?!?!" I've been there! You also now have to train people how to use each of those applications.
We are still going through this where I work. Previously IT was run on a bunch of Lotus Notes / Domino databases. Those have since been replaced by PeopleSoft and ServiceNow.
You have to see the opportunity for what it is. You can have real conversations with the departments about what their real needs are. It is going to take a while, but you will have to produce documents that detail the core application functionalities for all of the applications. Then you will have to map those functions into the ERP system. Once you have done that, you will have your gap analysis and be able to focus your developmental resources. You have to get buy in from across the organization and get people committed to and willing to do things differently. The ERP equivalents of the current applications will not be apples to apples. If you try to do that, you will never get through it and will end up failing. If you are just going to recreate the apps, you might as well not even bother. The key is to focus on the functionality. Focus on the business needs / business cases for the applications.
For something that big, you are going to need at least 3+ full time employees. A project manager to keep everything organized and fight back against scope creep, a senior developer / architect to make the technical decisions and provide guidance to the team of developer(s) who will do the actual work. In all honesty, what you are proposing is a significant investment for the organization and a shift in culture. Each one of those employees is easily a six figure salary, so figure over half a million dollar in salary (plus benefits, etc.) Good developers are hard to find and building a successful development team is a challenge. You will obviously need an executive sponsor who can help you figure out where to position this new group / department in the overall organizational hierarchy.
The long term benefit to your organization is that you free yourself from the vendor. The risk that you run is that you might end up with incompetent developers or management on the new team and find yourself worse off than before.
Have you considered bringing in another vendor? At the very least, you can use that as leverage to negotiate more favorable conditions with the current vendor.
You should have enough experience with the current vendor to determine how accurate their project quotes are. Use that knowledge when you ask them for quotes on replacing / reproducing the current application functionality. Then compare that to what it will cost your organization to do it in house. It should be clear very early on in the process if you are going to save enough money to justify such a drastic realignment of the management, operation and development of the systems.
My experience with them (having done at least 4 big Oracle and 2 big SAP implementations) is that if your business model fits the built in business processes in the ERP, it's pretty easy to do (aka Business in a Box). If you have some business processes that are not in line with their out of the box processes, it gets really expensive quickly and makes things very hard to get working. The most successful (2 on time on budget) implementations were both where the company would conform to the ERP business model for the modules it planned to implement.
Also keep in mind that there are strict approved ways to integrate with big ERP systems like this so that you don't break the upgrade chain later. It would be best to get someone in house, even if just on contract, who has done customizations to the ERP system and specifically the module you want to customize. Put that ERP expert, your business process expert, the core developer(s), and maybe a PM (if you need to) into a core team and let them run. Take small chunks at a time and write tests for data integrity so you know you aren't killing things when batch processing/etc runs.
Hope that helps.
What kind of "applications" are you building using data from your ERP system? The whole goal of having the system is to have this single, integrated software that does everything. Sure you can interface with it, but "best practices" would mandate you only do it when it's strictly necessary. Having a bunch of Excel spreadsheets running around kind of defeats the purpose of having your ERP in the first place.. I know the costs are always great, but if your ERP system can do what you want to achieve, then use it. You never know if the APIs are as great as you think they are, and I shudder to think of having to maintain 20 different applications using an ERP system whose data model might change ever so slightly over the years...
Also, plan your staffing. If you have the money to pay for Oracle, you have the money to hire one or two people in-house to manage and code on it. They can guide your consultants and keep them honest, without that expertise you can easily be wasting money. The best people are the ones that worked as developers at Oracle, don't count on people that studied to just get a certification.
We use an Oracle-owned (bought) ERP as well. We had pretty fantastic success during ERP upgrades with the external systems that used the API - which remains remarkably consistent across versions. I find it to be cheaper, quicker and more robust to build and maintain tools around the ERP than within it.
In any case, that business data absolutely belongs in the ERP, all I'm talking about here is the manner in which the data gets there.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
You didn't start your question with the sentence:
"I am the CIO for one of the largest HVAC manufacturers in the world."
So the answer is: I hope you either have a family tie to the company, or some other mechanism of having your voice heard.
Since you already have shown that the path is chosen and the consultants are already on the ground running with the conversion, then it's already too late.
See, really your problem is that you hired in people that don't know how to do the job, and that's the problem with the majority of consultants these days. If you have good people (consultants or internal) then good things are possible no matter what choice is made. If you have bad people, it doesn't matter either.. the outcome was based purely on whether you have the knowledgeable people in a decision making role and in positions to actually do the work.
It's pretty much hit or miss on successful or failure ERP implementations, the common thread is the people and management. Unless that's fixed, get ready for a rough ride.
There's one thing that I try to keep in mind, though, when traveling down the rough road:
Change the things that you're able to change and position yourself for the change that you can't. So that way, even though things don't go your way, hopefully you have a backup plan that is still possible in the event of failure.
Are you dealing with transactional data or historical data? If it's historical to perform any sort of reporting or projecting, I'd recommend a data warehouse or data mart.
You would have to spend some time determining your business processes and what you want to get out of your system.
ERP systems integrate with other systems all the time and most provide an open architecture to allow for this to easily take place via Web services or an API. One example is that an ERP is not a full-fledged asset management/work order system. It tries to be, but in most cases it isn't up to par with other EAM systems. Saying that, you still need to keep your HCM, FMS, FSCM data in your ERP. By integration with a Web service, you can create WSDLs to get data into other systems and they'll be updated via transaction or time.
The big question you want to ask is what is your system of record for each type of data. I.e. employee data would be in an ERP's HR or HCM system.
In the long run, you'll save lots of money by not interfacing but integrating and keeping your ERP as original as possible, no customizations but just configurations so you don't have to deal with problems every time you upgrade/patch the ERP or any system connecting to it.
Even the smallest amount of research about the cost and time to implement an ERP would indicate that it will cost a lot more than you think and customizing it to fit your specific business will take both time and a lot of money.
ERP systems are huge, extremely complex and when implemented incredibly essential to the running of the company.
If an ERP system goes down, the business stops. That is why you spend the time, money and consulting fees to have it
configured as a very high availability system. Esp when we are talking about a company of the presumed size you indicate.
The fact that you have apps running in Excel and Access is horrible, common, but very bad for a lot of reasons.
This problem might have been discovered while implementing the ERP.
Since you are already investing heavily into the ERP, making it part of that system makes the most sense to me.
The benefits of integrating these data and functionality reaps benefits across the ERP system.
Now going to Slashdot, where a whole lot of people you have non idea who is, nor what their real life experience with ERP systems
are borders upon irresponsible. Would you take the information offered by a pimply teenager on how to solve your problems? Or maybe
its an ERP expert, how do you know.
Since you work at a company that has a lot of resources, the prudent thing to do, is to find a consulting company with a proven track record
in the ERP you are working with (different from the people you already have) and pay them to come in and do a discovery of existing excel
and Access applications, map out their functionality and do an estimate for each one, how much it will cost (ballpark) to implement them in the ERP system
and give recommendations for each application as to its suitability for migration. There is likely no one answer for all of them.
I may have missed what you were asking - if you have spent millions implementing an ERP, you are attempting to use an ERP strategy over a "best of breed" strategy. This may be the motivation behind your CIO comments. If this is the case, your departmental applications should be dumped entirely and the business processes involved should be modified to fit the "best practice" processes built into the ERP. Where a department really has requirements for a separate system (this is a much rarer situation than most people think - especially in SBU's) a supportable interface to the ERP should be deployed. You are now supporting a hybrid ERP/BoB (which to some degree is often the case at most places claiming to be an ERP shop).
We deployed PeopleSoft here in 2006 with help of a third party partner - through diligent procedural development wehave become self sufficient even through major upgrades. A constant threat to our success has been the reluctance of process owners in the SBU's to even consider changing their business processes to match the vanilla processes delivered. More than once we have had to wait until a major decision maker retired to change processes only to find out the the new processes, after an initial painful adjustment period, are superior - better suited to our needs, easier to integrate, adapt better to changing requirements from users and governments, scale well and are easier to monitor and report on.
G
15 years solid Access experience!
Many people are into erotic roleplay and the important first step in coming to terms with it is to understand that you are not a freak and that your sexual preferences are your own.
I've seen companies spend ludicrous sums on TYRING to fit square ERP pegs into their odd ball shaped hole of business processes. Keep customization to a minimum. If you can't find an ERP system out of the box to do what you need it to almost completely, then building external apps to do what you want is not a bad way to go provided you have in-house talent to manage it.
Also make sure the vendor approves of what you're doing in those external apps. You might find them blaming you for system problems and not provide support when you need it most. You can bet the odds of this go up if you outsource the dev work. It's nothing for them to blame a third party they don't have a business relationship with.
Just remember -- external tools are basically external modules that are only dependent on the underlying data. As long as the database schema doesn't change, system upgrades shouldn't have any impact on your external tools.
You can throw good money after bad, and you probably will.
If you want to have an alternative, you could do worse than look at Oodo (formerly OpenERP) it is a python based, AGPL licensed ERP package that is modular with a sensible API that is growing an even more sensible API. It is not without it's problems, I wouldn't sugar coat it, but if it is broken, you own all the pieces (http://odoo.com source at https://github.com/odoo/odoo) and that is priceless.
Depending on your specific requirements it might work great, or might be a bigger pain in the ass than your proprietary mess. Like I say, you will almost certainly take the path of throwing good money after bad, but for anyone else at the front end of a decision, the business value of Free Software is huge.
ERP was always the one enterprise application to rule them all. Then came a Customer Relationship Managment CRM. Neither meets the goal. On the consumer side, small apps that work together meet the users needs via Application Programming Interfaces API's. And in enterprise, those Apps are replaced by spreadsheets, custom web views and other bespoke tools to help the user meet their goals. Dumping more money into the big ERP tool is just dumping more money. Give the people what they want and simplify your life with APIs and integrated apps.
I have been on several projects similar to the one described and I would caution that before diving into the build-vs-buy decision, I think you should re-evaluate and see if you're solving the right problem. At this point, having spent millions of dollars investing in your ERP it's not feasible to swap it out but it seems that most of the pain lies in the applications that MANAGE the data, the Excel spreadsheets, Access db's, etc. I would suggest looking into a front-end PaaS cloud solution with good dev and integration API's upon which to quickly re-build these apps, streamlining and standardizing processes and workflows - the situation you've described is a common case for cloud migration. You may want to look at a platform which will vastly improve time to app (Gartner and IDC have studies ballparking how much quicker you may realize time to app with a good cloud platform), lower your TCO and the OPEX vs CAPEX model may be more palatable to your accountants when evaluating costs of rebuilding. Also, like another poster mentioned earlier, you should try and avoid going down the path of heavily customizing your ERP because it will be a pain to upgrade, like it isn't painful enough already. I'd suggest having a platform layer upon which to build your apps, interfacing with your ERP via an integration layer. Without knowing additional details, I would recommend looking into the Force.com platform (disclaimer: No, I don't work for the company but I've designed solutions on this platform to solve situations like what the OP describes, migrating macro-ridden excel sheets, databases, legacy apps like lotus notes, etc. etc. onto the platform while integrating with an Oracle/SAP back-end so I'm comfortable recommending it). It's a good platform to build upon, literally hands-free upgrades, with numerous dev integration API's that guarantee backwards-compatibility, better up-time than Google and various integration middleware solutions as well so you don't need to rewrite connectivity interfaces for all your apps if you ever decided to swap out Oracle ERP for say, SAP. And the language is fairly simple to develop in, simpler than say, Java so you could get your third-party SI to lay the groundwork and then maintain/build upon it internally or, depending on your internal IT team's capabilities, take the bulk of the work on yourselves. Just my 2c, seriously - consider a cloud-based solution to solve some of your most pressing needs.
In theory, it makes life easier for the corporation, in practice, not so much.
We purchased a large ERP to 'centralize' and 'homogenize' our data. Instead if disparate systems trying to interface, we wanted all our divisions to use the same system. We had IT research the different options with occasional feedback, and they picked one, and we started implement it.
It turns out that we had disparate systems for a reason, and the new ERP system didn't fit into any of them. We adjusted models to fit the best practices of the ERP as best we could, but that only got us so far. At the end of the day the ERP was nothing but a database (SQL Server) and all the day to day operations were done with custom built applications interface through API's and ODBC. Occasionally, (but rarely) there will be a business need that happens to be implemented natively by the ERP, but it's not something we count on.
One of the original suggestions was that we just 'roll our own' solution. In the end, we did, but we first saddled ourselves with a large pricetag and mostly useless support contract.
--Welcome to the Realm of the Hawke--
When Is It Better To Modify the ERP vs. Interfacing It?
Modify the what?
I work for one of the largest HVAC manufacturers
A what manufacturer?
We've currently spent millions of dollars investing in an ERP system
A what system?
but it's been a great ordeal getting the thing to work for us across SBUs
Across what?
(via API of choice)?
Ooh, I know that one!
Our CIO
Chief... something... officer...
systemd is Roko's Basilisk.
The more you mod the ERP the more likely you will have to pay again to incorporate you mods in the next major ERP release. While developing your own solutions isn't cheap at least once they are working you will just (a big just) have to ensure your data feeds and APIs are still functioning properly.
I'm a consultant - I convert gibberish into cash-flow.
This is almost a philosophy question. While I haven't been directly involved with the implementation of an ERP, I have been at clients that were implementing large scale ERP systems. There are two main ways to deal with this. The first is to take the ERP system and make minimal changes to it and instead perform business process transformation to align the business with the ERP system. The second is to take the ERP system and use existing business processes with minimal modifications and instead modify the ERP and/or put in place interfaces/API's to make the ERP work with the business processes. The answer is not always easy. Many places can benefit from business process transformation because processes have been used for a long time and don't take into account the current environment, they haven't been changed because "this is the way we've always done it". Sometimes the business processes are optimized and your better off changing the ERP and/or putting in the interfaces.
-- Slashdot, making the Left look conservative since 1997.
Your CIO is obviously getting his dick sucked(*) by the vendor. Your accountants only care about this quarters bottom line.
You have two realistic options. 1) Come up with a way to pay over time, so that the bottom line hit every quarter is not too big and your CIO continues to get his dick sucked.
or
2) Propose a huge project that you will lead to replace everything with this super system using all sorts of outside vendors and integration. You will obviously need a big team and huge budget to pull this off. Just be sure to change jobs, either internally or externally before there are any deliverables, so you can blame your successor for the steaming pile you end up with.
(*) I mean this in the generic, so if you CIO is a she, then obviously, she is getting her pussy eaten.
What your CIO should be doing is bringing together two (or more) separate proposals to the executives who then mandate that all department heads provide cost estimation and risk analysis for each of the two scenarios. Once all those are compiled together, cost and risk can then be used to help the CIO and other executives make a choice. Then they can once again mandate a conformance of all departments to the chosen solution and give the department heads X amount of time to convert N percentage of their business processes to the chosen solution. Iterate until all legacy systems and processes are sunset.
Choosing one technical solution over another or choosing to pay a cost here versus there makes absolutely no sense until you completely understand the needs, resources, timelines, and risks.
lets go play a round of golf and talk about your ERP pain points. I have an entire toolbox of open source automation, integration, and acceleration products that we can use to fix your woes
The title and the first couple lines with all the acronyms and Im pretty sure we just saw the output of a Turing test...
I used to work for an Aerospace Manufacturing plant, and their ERP system M1 wasn't cutting it. I developed a complete web-based portal system that interfaced directly with the SQL server to bring the data to life. I now sell my software I made to other businesses that use the M1 ERP system and customize it to their needs. I highly recommend that route. You won't be disappointed when you see your data come to life in an orderly fashion.
Just me
I work for the largest medical testing company in the US. We use some Oracle products, but we also do a lot of integration of other products into it. The reason is obvious, speed of development, and cost. I don't think I've ever worked at a large company that didn't do integration into something like SAP, or Oracle.
I've been involved in 5 of these ERP conversion efforts. The ones that failed used big expensive commercial products and giant teams of consultants. Hugely expensive. Kinda limping along. Both of the successes were outfits that decided to just build what they needed inhouse, skipping consultants and giant ERP packages.
My head wants to explode just thinking about their procurement and payables modules
No, not that DRM, I mean Data Relationship Management. It's designed for taking that manual excel spreadsheet crap and turning it into an actual process. I should know, I integrated the JS engine into it. You can version the data, blend (merge) it, and so on and create workflows.
I don't feel bad mentioning it since I'm leaving Oracle shortly to join a startup, but that's my full disclosure.
Natural != (nontoxic || beneficial)
ERP is a fairly well understood acronym in this context (slashdot). Also Google (ERP is the first search result)
Your post wasn't proofread - looks like you're missing a word.
If the ERP system is not working for you, then just hiring internal developers is not the solution to your problem. You need to go back and find out what went wrong, and where it went wrong in your system design and architecture process. It sounds like the problem you have isn't "not enough code", but rather, poor management of the design process. It sounds like you guys are mixing methodologies that aren't intended for an ERP projects of this scale. In fact, based on what you describe (user-driven development), the users weren't very involved in the early design to lay out what their needs are for this system, especially on the reporting end. So your BI system got the Business side right, but it seems the Intelligence part is lacking.
TLDR: go back to the drawing board and figure out where the design was fudged. Then, take the time to produce a proper design with proper user input. Lastly, select a methodology that works with your organization's structure and is in-line with the business strategy. Make sure to include the proper people in the design committee (especially top management), and produce a proper design document that the users will sign-off on. Only then can you begin to shop around for the solution that best fits your needs...and it may even be Oracle...but at least you will be able to better guide your consultants in them providing you with exactly what the users actually need. Also, consider the roll-out process...look at a pilot roll out, or another phased approach...don't EVER do cut-over!
Huh? [devShell.org]
sooo, let's see if I got this right:
- you "spent millions of dollars investing in an ERP system"*,
- then you "discovered" that the system only does input/output
- so for managing the data you use "systems of spreadsheets and access databases wrought with macros to turn them into functional applications"***
- on top of that you have empty data centers you can't really find any good use for****
- and you just learned some new buzz words related to cloud technologies but heard someone say cloud is counter productive+
- now your "CIO wants to dump everything" (as in throw the garbage) into the ERP but the accountants don't want to pay up
- so you're asking for our advice +++
If I were you I'd tell the CIO I'm "on it" then go play golf or make myself seem busy. From time to time report that there was progress but you need more time and maybe an assistant. Prepare a nice looking excel for days when he actually wants to see what you've been up to. If he wants you to explain this to management, prepare a nice PowerPoint with colorful graphs and a few acronyms and buzzwords (use the cloud words you learned).
Since I'm not you, I offer you my services as a contractor for a modest fee. I'm sure I can come up with a figure that your accountants will be willing to cough up and will enable me to retire comfortably. I have enough experience to make your boss believe he's getting his money's worth and can make nice presentations to upper management.
* you mean wasted millions, not spent or invested**
** "spent" or "invested" would be words used by Larry Ellison or your incompetent third-party implementer
*** gasp. someone please help! This is like taping a cardboard on your overpriced Bentley to block out the sun and then using a piece of string to tie a shopping cart to it when you go to Walmart's.
**** how about selling them or putting the place up for rent...
+ what (wtf) does cloud have to do with your ERP woes? Besides, why talk about cloud if your DC is idle? The whole irony here is that ERP is counter productive. ++
++ I had too many stars to signify footnotes so I decided on using pluses instead.
+++ I know you asked for our experience, but you're really looking for a way of making everyone happy.
sigo ergo sum
"Business Intelligence"
Reading between the lines, and with over 20 years experience of working with Oracle E-Business Suite, when you say 'managing' data, what you really mean is 'analysing' data. I agree Oracle E-Business Suite is primarily a 'repository' for the data, and typically the analysis is done with Business Intelligence tools built on either the EBS database directly, or on a dedicated data warehouse. The canonical product you would use is Oracle BI, but there are free tools probably just as good like Pentaho, Jaspersoft et al. Probably the only major benefit of using Oracle BI is that it comes with E-Business Suite specific queries and dashboards pre-built and configured.
MrCreosote Meow!Thump!Meow!Thump!Meow!Thump! "You're right! There isn't enough room to swing a cat in here!"
Just quit.
1. You don't seem to be the one in control of this project. So, you are stuck on this path. Or, do you have the political capital and will to fight to get your way? You're seriously going to piss in someone's Wheaties and when you're standing in the shower in the morning, you better have a smile on your face knowing it's worth it.
2. You work for a major HVAC manufacturer. That's the most exciting thing you can do with your life? It would make me want to slit my wrists every day with a spoon.
3. You have to re-do these applications and make the data integrity robust. That means seriously looking at things like where you can get the most benefit for least amount of cost and/or where the data integrity is shit. "Oh, Jim manages our entire Northwest supply chain and inventory using that Excel spreadsheet he keeps on his desktop." I don't care if you use and Oracle product to get there or a cloud-based, super-redundant shade of the color blue. The only thing your boss's boss cares about is whether you a) prevent the company from losing money or b) make the company more money.
4. Speaking about data center room makes you sound like a systems or support person. This is an application and developer thing.
5. I'm not sure I understand where your pain points are. Customer relationship management? Supply chain? Inventory? Quality control? Payroll/HR? Quantify.
6. Do they pay you enough to worry about this? That might seem flippant, but it's very valid.
----- obSig
> I'm talking useless to the point where they were just sitting next to me and searching Google for answers to the problem we brought them in to solve.
Don't underestimate how many problems this can solve or be too proud to resort to it if you want results.
I've solved many customer problems by searching for the right part of RFC 2616. For example, to say that the content length header is NOT "missing," we're using chunked transfer encoding which doesn't use that header and your other system lied about supporting HTTP/1.1, because CTE support is a MUST per the RFC. Or to point out that they have a common OS error, rather than a product error. I don't work for Oracle, but they are a reseller of one of our products.
In other words, many of the questions I get can be answered via SO or Google, but nobody prior to me thought to try that.
Tesla decided to dump canned ERP and build their own. I think this is super smart, you design your own data model to exactly fit your needs, it changes as the org changes. People do not understand that complexity in software (wherein people in the organization have to remember that "Leads" are actually "Patients", which happened for real when a Health Clinic paid $$ to use Salesforce) leads to dysfunction in business processes. If your software makes sense and a common vernacular is cultivated with the smart use of a custom data model (i.e. call things what they are), your organization can be focused on core competencies and not burn a lot of calories dealing with poor software choices. Here is a link to a recent article describing Tesla's choice to go this route:
http://www.mendix.com/think-tank/tesla-cio-builds-erp-house-4-months-says-time-erp-upgrades
Explodes!
So. Much. Corporate. Blather! So. Little. Meaning! MBAs. Gathering. Like. T1000. Pieces!
Please look at the "out of the box" features of Odoo v8: :)
https://www.odoo.com/
After looking at what Oddo can offer, please consider using ITpedia Solutions to help you implement Odoo, and save significant amounts of money (well under $500K for full consultation, training, implementation, customization, and support packages
Your Full Service Partner As a full service partner of OpenERP/Odoo, ITpedia Solutions LLC is able to provide: ERP and business software gap analysis, consulting, planning, project management, hosting, implementation, configuration, software development, training, support, and maintenance. We specialize in customizing OpenERP/Odoo through the development of one-of-a-kind module solutions. We can also offer significant discounts on Odoo services as well.
Our Team of Experts
Our team consists of experts in the fields of finance & business consulting, information technology, and software development and engineering. Many are software programmers and system administrators, which enables ITpedia Solutions LLC to implement ANY business software requirement. Our software engineers have experience in connecting OpenERP/Odoo to a wide variety of 3rd party applications and services such as Magento, Prestashop, Pentaho Reports, Amazon, eBay, Authorize.net, stamps.com, Fedex, UPS, and more.
24/7 Work Day
We can rapidly ramp up multiple OpenERP/Odoo experts to ensure your project development is worked on 24 hours a day until completion.
On Premise or Remote Project Access
You will have worldwide access to your OpenERP/Odoo solution via either the ITpedia-Solutions SaaS Web Application (which uses private "cloud" IT infrastructure), or assisting with on premise solutions. Our innovative OpenERP/Odoo systems and software engineers can be secured to contribute to your current OpenERP/Odoo project either on-premise or via remote technology.
Contact Us
At any time you can use the contact information to contact us to discuss any OpenERP/Odoo or IT issues or to find answers for any questions. Thank you.
ITpedia-Solutions.com Baltimore: 443-574-ITPS (4877) MD/DC: 240-343-ITPS (4877) VA: 703-828-ITPS (4877) Skype Name:
In my experience, the word "Enterprise" usually means a shitty piece of uselessly generic and hopelessly complex software combined with an expensive consultant team who spend 5% of their time configuring/using the software as intended and 95% of their time hacking around its limitations by glomming on little "tumor" systems to shoehorn it into your business.
But I admit I'm a little jaded.
I am actually writing a book on managing large projects that have gone to crap, and can say that you are being trapped in a classical routine where they will deliver what you ask for but not what you need. Then they will nail you when you realize that it wasn't what you wanted and will again deliver what you ask for but not what you need. Companies like this often will cultivate a great relationship with the most dysfunctional aspects of your organization who will ask for the most useless things.
The key is that you can never sue them as they will deliver exactly and contractually what you asked for. It doesn't matter that you asked for a Toyota Corolla with a trailer hitch to pull a full sized tractor-trailer sized load. That is what they will deliver. Then they will deliver an engine upgrade, a frame upgrade, a transmission upgrade, tire upgrades, etc. When they could have just delivered a truck as what you wanted was not what you asked for.
So the first thing is not to think about how to get this project back on track. What you want to do is to figure out where you are, and where you want to be. Then draw a straight line to there. What you might discover is that what you want is actually close to where you are, thus continuing with this debacle might be the answer. Or you might find that it is actually a shorter path to success from basically nothing.
Going mostly or entirely in-house is a good idea except that you might find that you have gone from depending on one bunch who don't seem to get things done to another who also don't get things done. So make sure to chunk up the project into pretty separate chunks. Then see who gets things done and who doesn't.
Needless to say the whole process has many more steps and more decisions (hence a whole book) but at least you don't need to feel bad about it going to crap; most projects do. But of all the discoveries that I have made simply using logic and common sense is a massively powerful tool. If something doesn't seem right then it probably isn't. If they say, "You need this 1 million dollar solution for this tiny bit." think about what is similar and how much that cost. Also be prepared to trim functionality if fairly useless things are holding things up. I have seen people build systems that could have been done in a day or two in Excel except for later unused features that required that some poor group of programmers basically had to build their own excel like application from scratch. So here was a project that cost millions that literally could have been done in house by an accountant over a weekend. At the same time I have seen people try to short-cut by using a tool like excel which resulted in a huge mess of worthless crap when it should have been done in something more like C++ in less than half the time. So there is no one answer.
So while getting it right can be hard at the best of times; it becomes nearly impossible if your development company is incented to work against you. Thus be prepared for an interesting battle merely sorting that aspect out.
Having just been involved with interfacing a line of business system with SAP I have learnt the following:
- just because a vendor is large, does not mean that their product will be good [for your situation]
- make it clear as early as possible that comprehensive documentation of the interfaces is required (probably too late for you)
- ensure you understand the business rules of the system you are interfacing to and implement them in your systems too (otherwise you will end up with a mismatch which results in data failing to be sent via the interface causing all sorts of problems especially if the data must be processed sequentially e.g. inventory transactions)
- if you need to have customisations made to the ERP system consider that you may be better off having your own custom in-house solution, as a heavily customised ERP system will likely kill your upgrade path and require extensive testing (eliminating the benefits you hope to receive)
- have clearly delineated & agreed upon lines of accountability / responsibility between finance, IT, and operations - this will be essential when [teething] problems are encountered down the track and teams are arguing about whose problem it is rather than fixing it.
- if the project requires significant resource then consider back-filling the BAU roles with contractors rather than hiring contractors on to the project team. This ensures that the project team's interests are aligned with the long term interests of the BAU teams. This also ensures that the project team has a more complete / nuanced understanding of the business.
- consider the long run when designing how a system will interface, e.g. when having mapping IDs in the legacy system to the ERP system's IDs, consider if a snapshot of the mappings (or other state information) needs to be kept against transactions as they occur to preserve the relational integrity of historical transactions (especially for troubleshooting when you're asked why is 123 showing up on X when that customer is mapped to Y).
Also just as a side note... resiliency should be a function of the application / system architecture rather than dependant on whether you have one massive system that does everything vs many smaller systems that communicate with each other.
...but it's been a great ordeal getting the thing to work for us across SBUs and even departments without having to constantly go back to the third-party, whom have their hands out asking for more money.
I see Oracle hasn't changed much since I tangled with them in the late 1990s.
The biggest failure for almost all ERP systems is a failure to put enough effort into making a reasonably comprehensive functional specification, and getting all departments effected by it to sign off on it. Without this definition of work, and buy-in by the departments, you get stuck in the cycle that you're evidently in -- specification creep, and the resultant contractor scope creep.
Sadly, management is the cause of this. They hate spending time and resources doing "unproductive" things like defining the work to be done. So they force people to start building subsystems before they fully understand what work needs to be done to build the overall system. Then they complain when all the work they insisted be uncoordinated, doesn't integrate together. And... they'll blame it all on you, because how could it possibly be them? Sigh... been there and done that way too many times.
So... what can you do about it? You can a) live with it, b) try to build a decent and accurate functional specification for the system even now (good luck getting management to give you the authority and the manpower), because if you don't ever define how the system works as a whole, you can't ever get the parts of it to integrate together, and c) take what you've learned and try again at another company. Sorry. Not what you wanted to hear.
If it makes you feel any better, it wasn't what I wanted to hear either. And it's one of the reasons I retired as soon as I did. Life's too short to put up with more of this bullshit than you absolutely have to.
Disclosure : I am development manager for a software consulting firm specializing in ERP and CRM implementations and integrations, customization etc etc.
As has been mentioned before, depending on the architecture and capabilities of the ERP package, sometimes there are levels of customization you can achieve that do not modify the core application. But generally speaking, it is almost always better to interface where the ERP system does not meet/fit/support the requirement.
Leaving that abstraction layer is critical to being able to upgrade, change out systems etc. This can be via custom app that feeds module X in the ERP, custom app or third party application that replaces a module of the ERP for some particular aspect the ERP doesn't do the way you need it to.
While there is complexity there, at the end of the day there will be complexity somewhere anyways so you might as well define where its going to be vs having it organically accumulate.
If your organization can support the staff, you should have in-house folks who are dedicated to the design and interface specifications and implement some monitoring tools for the interfaces so you can be proactive when things hiccup ( and they will ).
Others have commented regarding the fit the business vs fit the software debate, often though it can be more useful to step back and have a user or group that don't have ' a dog in the fight' to review the requirements and actually drill in on what the business needs vs what the departments think they need. I have seen this countless times where some process or function could be drastically simplified but isn't because of internal political agendas.
While we are happy to take your money, as a consulting company we actually do try to give the answer in the clients best interest, which includes no,don't spend 1 mil on this when you can just x,y,z for a 10th of that cost and realize the same or better result. Not all consulting firms are like that of course, and in my experience the larger they are, the less likely they are to dissuade the client from the expensive ( and often incorrect ) choice.
Best of luck with your project.
"Our CIO wants to dump everything into the ERP (creating a single point of failure to me)"
Just because it's a single system doesn't make it a "single point of failure"
What are you going to do, have multiple ERPs with duplicate data?
No - you have redundancy - redundant servers, databases, co-lo, internet/network, etc. A strict upgrade/fix testbed to test all core changes completely before ever putting them into production, etc.
All the company data in one place isn't necessarily a bad thing.
The problem isn't: ERP customization or bolt-ons. The problem is that your organization has failed to understand how an ERP is implemented. It is NOT a IT project, it is a business project that should have the expectation that in nearly every case your organization will align its business practices to what the ERP offers. The ONLY exceptions are those where your company has a genuine competitive edge and they should be few and far apart.
I have been a part of both SAP and Oracle ERP deployments as an insider (never a consultant). Companies fail at these when they are not actually willing to change how they do things. That change must be driven by the CEO/President him/herself.
Implementing ERP is the hard part. Now leverage that investment. Build in house expertise around oracle web / cloud development tools and data analysis tools to build the dashboards, reports and tools that your buisiness units need. These will be extensible and upgradable with future versions of erp suite. Data extracts and bespoke adjunct systems will inevitable become a pain to maintain and seldom serve the business well in the long run. Assuming you've gone to the effort to implement a full suite including financials ( gl, ar, ap), order entry, mrp, maybe crm or logistics, you now have sound data for decisions that will make the business more efficient, productive, and profitable. Oracle tools and data appliance are relatively cheap compared to your overall investment and can deliver real benefits to the business much more quickly that bespoke systems. Speaking as a former oracle consulting executive, I have seen many firms drag along old home grown systems or build new "solutions" around open source s/w on commodity h/w because it seems cheaper, but over time these become an end in themselves rather than a driver of business improvement. The mission of IT should be to capitalize on the investment made implementing the core systems to help the business become more profitable. In short, your CIO has it right.
"Virtual Instrument Software Architecture" ?
Should have stuck with your old ERP system on (my guess) an HP and saved the millions.
Stromasys has an emulator for that too.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
If you need a powerful ERP with complex process, in multiple department you need a serious ERP. What you didn't do was budget for a full implementation. You can get rid of the 3rd party and the implementation part much cheaper than using your existing implementation partner for everything though.
I know a company that specializes in converting legacy systems over to new system and doing these sorts of Integrations that also has a strong staff development staff aug model (http://bluelotussidc.com/contact/contactus.php )
If possible, write a parallel application that meets you needs and interface to the off-the-shelf-apps. Use a database and toolset that is easy to use, like one of the inexpensive database out there. Your Oracle app remains the same. That way you can meet your needs without having to meet more strict requirements, such as accounting. And, the company saves face over their expensive app. Use the spreadsheets as the starting point, that the users have developed. That saves you a lot of $ right there. And, make sure that your responding to user needs this time around, not to IT requirements. That way you'll avoid spending lots of dollars for little benefit and loading your end users down with a lot of extra work for nothing.
With today's open source ERP, you don't need to choose between "do it yourself" or use a proprietary software. Check Odoo, the #1 Open Source ERP. You can reuse existing apps according to your own needs (it has 4000+ modules) but you can also control it and host/maintain it yourself. It's not 100% thrid party vendor or 100% in-house. You can do in-house what you want and benefit from external applications and, even external services if needed (upgrades, support, ...). With an open source solution like Odoo, you put the bar where you want.
Fabien