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 ----
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.
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 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.
Ummm, what's ERP?
They're that family that had a Gunfight at the OK Corral. There was Wyatt ERP, Virgil ERP and Morgan ERP....
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
On that list, Hershey (SAP), Nike (i2), HP (SAP), etc, etc, etc.
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.
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!
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.
He isn't looking at it backwards and does indeed have three serious business concerns. The business is concerned about shelling out to the third party consultants for every little change, concerned about data silos in the form of the spreadsheets, and concerned about future scalability in light of concerns 1 and 2.
I say definitely move development in house for this large of an ongoing project.
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.
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.
Submitter should use smaller words. He's trying to swim in the deep end ("whom", "wrought") when he's barely ready for the kiddy pool.
Amazingly, even in light of this new information, nobody cares. Nobody even cares that you are an asshole. Nobody cares. Just, go back to your basement.
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.
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.
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.
I care. Language cries when you abuse it like that. It makes me sad. Think of the small words!
Socialism: a lie told by totalitarians and believed by fools.
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)
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
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.
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 )
I don't underestimate it, I use Google to find solutions to problems all the time. Google has more answers to problems with Oracle software than Oracle's official documents do. The point I was trying to make is that we wouldn't be spending money to hire consultants if Google had the answers to our questions. We never brought consultants in for any problem that we hadn't been trying to solve via an SR through our official support contract for at least two or three weeks and we were always well past the "have you checked Google" stage of problem solving, yet the consultants provided by Oracle (for outrageous fees) never had any useful contributions or problem solving approaches beyond "Google it". We were trying to hire knowledgeable professionals with experience troubleshooting problems with very specific pieces of a proprietary software component. What we got were living versions of lmgtfy.gom
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