Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Elon Musk Approaches IT At Tesla

samzenpus posted about a year ago | from the try-this dept.

Businesses 231

onehitwonder writes "In short, they build it themselves. When Tesla Motors needed to improve the back-end software that runs its business, CEO Elon Musk decided not to upgrade the company's SAP system. Instead, he told his CIO, Jay Vijayan, to have the IT organization build a new back-end system, according to The Wall Street Journal. The company's team of 25 software engineers developed the new system in about four months, and it provided the company with speed and agility at a time when it was experiencing costly delivery delays on its all-electric Model S."

cancel ×

231 comments

Sorry! There are no comments related to the filter you selected.

SAP (5, Funny)

Anonymous Coward | about a year ago | (#45328841)

S - end
A - nother
P - ayment

Re:SAP (4, Funny)

Reverand Dave (1959652) | about a year ago | (#45329267)

We always called it Sorry Ass Program.

Re:SAP (1, Funny)

ArsonSmith (13997) | about a year ago | (#45329989)

Sap n.

1. To undermine the foundations of (a fortification).
2. To deplete or weaken gradually.

http://www.thefreedictionary.com/sapping [thefreedictionary.com]

Re:SAP (-1)

Anonymous Coward | about a year ago | (#45329813)

S - Stop
A - American
P - Production

Re:SAP (1)

Anonymous Coward | about a year ago | (#45329993)

S - low
A - nd
P - ainful

Now Open It (1)

GeorgeHahn (3287255) | about a year ago | (#45328861)

More competition to the likes of SAP can't be a bad thing.

Re:Now Open It (2)

cusco (717999) | about a year ago | (#45328933)

Did you see where it only took 4 months? I haven't seen an SAP **upgrade** that went that fast, much less a deployment.

Re:Now Open It (5, Interesting)

tgd (2822) | about a year ago | (#45329259)

Did you see where it only took 4 months? I haven't seen an SAP **upgrade** that went that fast, much less a deployment.

Of course, the reason for that isn't the (complete) ineptitude of people at SAP, or the superstar statusing of the engineers at Tesla.

Its easy to build a one-off solution that works for what a company needs on day one, do it quickly and be successful. Its vastly harder to build a one-off solution that still works for what the company needs done ten years down the line. And damn near impossible to build a one-off solution that just magically has equivalent success and value to other companies just by open sourcing it.

SAP upgrades can easily take that long, but SAP can easily run organizations an order of magnitude bigger, and two orders of magnitude more complicated than Tesla.

IMO, the key thing people should get from this is the importance of making sure you buy what you actually need. If Tesla could replace their SAP system in four months with 25 engineers, odds are pretty high they had overpurchased when they went with SAP to begin with.

Re:Now Open It (4, Interesting)

h4rr4r (612664) | about a year ago | (#45329363)

Maybe they exist, but have you ever seen a company that actually could deploy or upgrade SAP faster than building something in house?

Re:Now Open It (2)

tgd (2822) | about a year ago | (#45329831)

Maybe they exist, but have you ever seen a company that actually could deploy or upgrade SAP faster than building something in house?

Depends how complete their understanding of their immediate, short term and mid-term requirements are.

I'd say yes, for companies that actually had a good handle on their requirements. I also think most companies are bad about calculating the real costs of doing a complex system like that DIY. Its easy to enumerate the up front costs, but much harder to enumerate the costs over time of support, enhancements, and hardest of all, operational inefficiencies because the system couldn't do "X" and there wasn't time, resources, understanding, etc, to implement it.

Re:Now Open It (2)

h4rr4r (612664) | about a year ago | (#45330007)

I think all that stuff is just as much a problem with SAP. Lots of costs because it did not do X on launch day.

Not saying you're wrong, just saying it is not unique to building in house.

Re:Now Open It (4, Informative)

CastrTroy (595695) | about a year ago | (#45329401)

The question is, does the company even know what it's going to be doing 10 years down the line? Does SAP make it any easier to change as you company evolves over the next 10 years? SAP isn't something you can just install and forget about it. It's just a set of tools. It's like a database server, web server, development environment, or operating system. Similar to SharePoint, except bigger. It doesn't do anything on it's own. You have to do a lot of work to make it work for you.

Re:Now Open It (1, Troll)

smooth wombat (796938) | about a year ago | (#45329853)

does the company even know what it's going to be doing 10 years down the line?

Probably not, though in Tesla's case if they keep having their cars burst into flames when they get into an accident, they may not be around in 10 years (that's not a slap, just a comment).

Does SAP make it any easier to change as you company evolves over the next 10 years?

Hell no! SAP doesn't make it easy to change, PERIOD.

SAP isn't something you can just install and forget about it.

Don't worry. Once you install SAP you can never forget about it with the constant changing of screens to perform the simplest of operations.

Similar to SharePoint, except bigger.

If you were trying to extoll the virtues of SAP, you failed miserably.

It doesn't do anything on it's own.

It doesn't do much when you're using it other than get in your way.

You have to do a lot of work to make it work for you.

I thought the purpose of SAP (and Oracle) was to make my life easier. Why should I have to do a lot of work to make it work?

Re:Now Open It (3, Funny)

NatasRevol (731260) | about a year ago | (#45329475)

SAP can easily run organizations an order of magnitude bigger

I lost it at easily.

Re:Now Open It (4, Funny)

Pope (17780) | about a year ago | (#45329533)

It is easy! The users and their business models are simply all wrong LOL

Re:Now Open It (5, Funny)

fatphil (181876) | about a year ago | (#45329995)

>> SAP can easily run organizations an order of magnitude bigger

> I lost it at easily.

I misread it as "SAP can easily ruin ..."

Jack of all trades, master of none (1)

Anonymous Coward | about a year ago | (#45329517)

The key thing people should get from this is that shoe horning a 'generic' monstrosity like SAP into any business is no way to meet a company's individual needs. SAP may do many things 'good enough' but it also does many more things like 'crap', because it's generic. If you simply want to burn money on untrained monkeys, SAP is for you and you'll pay for it (through the nose) for the remainder of your days. But if you're serious about your business and making the most of your IT resources, you don't hobble the company with an infrastructure that 'sort of fits'.

Re:Now Open It (1)

Lumpy (12016) | about a year ago | (#45329757)

"or the superstar statusing of the engineers at Tesla."

I heard that they look for people that demonstrate they are good and ignore fake things like degrees that do not show aptitude or drive.

Granted this was from a friend of a friend that worked there as a drive systems engineer, he claimed that he was recruited by Tesla from his work on electric cars he was publishing online.

Re:Now Open It (1)

ObsessiveMathsFreak (773371) | about a year ago | (#45329973)

SAP upgrades can easily take that long, but SAP can easily run organizations an order of magnitude bigger, and two orders of magnitude more complicated than Tesla.

From the comments I'm readin in this story, my take home messege here is that SAP probably shouldn't run organizations at all. What the hell does their software do for all this expense and hassle anyway?

Re:Now Open It (5, Insightful)

dysmal (3361085) | about a year ago | (#45329273)

Everyone knows of a company that is implementing SAP. Can anyone name a company that has completed their implementation of SAP?

Re:Now Open It (0)

Anonymous Coward | about a year ago | (#45329727)

yes, just don't ask for the documentation because they skipped that part.

Re:Now Open It (0)

Anonymous Coward | about a year ago | (#45328941)

The joke with SAP is that you'll need so many man hours to shoe it in for your organization that you might just as well build from scratch in c. It just pays better to do it with SAP, since it's an easier sale because nobody ever got fired for buying an Enterprise grade solution.

Re:Now Open It (1)

Kookus (653170) | about a year ago | (#45329601)

SAP can handle payroll, and some organizations actually use that functionality. Let me know who you've found that kept their job after messing up payroll (who isn't also sleeping with the boss).

Enterprise or not... you're toast.

Re:Now Open It (1)

Lumpy (12016) | about a year ago | (#45329795)

Oracle seems to be able to. They blew up payroll for a large company, Comcast. Completely pooched payroll right after the AT&T merger and pissed off a ton of people.

Re:Now Open It (0)

Anonymous Coward | about a year ago | (#45328979)

You will only find that it will cover about 1% of the total SAP functionality, and it will not be the 1% you happen to need. Surprisingly, you will likely also find that there is only 1 company in the world whose requirements it meets.

Re:Now Open It (2)

steelfood (895457) | about a year ago | (#45329123)

Their system is probably custom-tailored to their business processes. Not only would it not be appropriate for many other businesses and thus have a very small market, but it could also expose some of Tesla's secrets on how they operate, which would then give their competitors (enemies really, because they have no actual competition at the moment) an advantage over them.

They could theoretically invest more money into its development to make it appropriate for mass market consumption. But entering the business software market may not be something they want to do at this very moment. And after pouring additional dollars into the project to make it more generic, it wouldn't be exactly a good use of resources to just open source it either. Nor might it be possible if it makes use of someone else's licensed proprietary technology.

Nor for Tesla next year. Build, Buy, FOSS (2)

raymorris (2726007) | about a year ago | (#45329419)

Given that they only spent a few months on it and don't have experience building broadly applicable SAP systems, we can be pretty certain you are correct in this statement:

> Their system is probably custom-tailored to their business processes. Not only would it not be appropriate for many other businesses ...

It's probably still true if we change a few words:

> Their system is probably custom-tailored to their current business processes. Not only would it not be appropriate for many other businesses, including Tesla a year or two from now, ...

Generally, you should build within your core competency, and buy generic systems for generic tasks.
Tesla should design their own cars, especially electrical subsystems of the cars, but buy trashcans, spreadsheets, and SAP.
Their SAP needs aren't that different from the next company down the road.

In a gray area, where you need something customized to your needs, but it's mostly the same as what other companies use, FOSS fits the bill. You get the 95% of common functionality free, then build the 5% that's unique to your needs.

Re:Nor for Tesla next year. Build, Buy, FOSS (4, Insightful)

blackraven14250 (902843) | about a year ago | (#45329645)

I mean, Tesla's core competency is definitely cars, but it's not like they're unfamiliar with software development. It's quite different rolling your own when you're just an auto maker with no history in software. Not only do Tesla's cars require more software and firmware than the traditional "competition", but they also have leadership which is absolutely competent in software development.

No article (5, Informative)

Anonymous Coward | about a year ago | (#45328873)

Don't bother clicking through - nothing but the same summary.

Re:No article (1)

s.petry (762400) | about a year ago | (#45329205)

Yeah, at first I thought it was adblock/noscript. There is nothing here to view even after I disabled those extensions.

A risky gamble (1, Informative)

girlintraining (1395911) | about a year ago | (#45328877)

Many, if not most, IT initiatives with homebrew tech fails. It's nice when it pays off, but almost always it is over budget and under spec. If the CEO got lucky, good for him, but his CIO shouldn't be sitting in the big chair if he didn't at least warn him it could all go horribly wrong.

Re:A risky gamble (4, Insightful)

gaudior (113467) | about a year ago | (#45328935)

How many SAP installs come in at or below budget? How many are actually completed at all, let alone on-time?

Re:A risky gamble (4, Funny)

Anonymous Coward | about a year ago | (#45329255)

*Crickets*

Re:A risky gamble (4, Insightful)

nbvb (32836) | about a year ago | (#45328951)

I disagree.

Some of the most successful IT shops I've ever worked in have been 'build' vs. 'buy' shops. They get tremendous cost advantage from having internally-developed tools that exactly meet the needs of their business.

Done right, it works very, very well.

Re:A risky gamble (2)

girlintraining (1395911) | about a year ago | (#45329025)

I disagree. [...] Done right, it works very, very well.

Yes, the same can be said for any risk-taking behavior. "I haven't worn my seat belt for years and nothing bad has ever happened to me."

Re:A risky gamble (1)

Anonymous Coward | about a year ago | (#45329115)

But spending millions of dollars on an SAP implementation that doesn't get done in over twice the agreed upon window, costs 4x as much as projected, and wasn't able to fulfill its goal is risky too. Or at least that's what the people who pay me to write custom software said about their attempt at it.

Re: A risky gamble (3, Insightful)

jd2112 (1535857) | about a year ago | (#45329199)

Risk vs. reward. What have you gained from not wearing seatbelts other than perhaps a few less wrinkles on your clothes?

Re: A risky gamble (1)

LoRdTAW (99712) | about a year ago | (#45329617)

"What have you gained from not wearing seatbelts other than perhaps a few less wrinkles on your clothes?"

They gain the smug ability to say: "Fuck-the-gubberment I ain't wearing no seat belt. dis heres a free country and I can make my own dumb decisions"

Re: A risky gamble (3, Insightful)

girlintraining (1395911) | about a year ago | (#45329657)

Risk vs. reward. What have you gained from not wearing seatbelts other than perhaps a few less wrinkles on your clothes

I have learned that most people are utter shit at estimating risk. Especially people who think they're smart and are good at it, but don't actually do the math. We spend trillions to prevent terrorism, but next to nothing to prevent drunk driving. It's because people think that risks they have control over are far less than those they don't, so drunk driving is "Well, I'll be driving, and I'm a good driver, so the risk must be low", and terrorism is "I'll be strapped into the plane and not in control... so it must be much, much worse."

The same kind of thinking applies to rolling your own software, instead of buying it. People are not objective about risk. They flat out suck at it. As for me... what I've learned is to wear my goddamned seat belt, because I read the statistics and know that there's about a 1 in 5 risk of getting into a car accident every year, and the seat belt means a 90% reduction in probable injury -- Without it, I'm just hamburger through the window.

Which is like most companies when they decide to cook their own complex software... they usually wind up paying more, but because they never analyze their own decisions, they, like you, think it's actually less.

Re: A risky gamble (2)

cusco (717999) | about a year ago | (#45329849)

On the other hand, the statistics about SAP rollouts would tend to indicate a very high degree of risk inherent in attempting to use that system.

It very much depends (0)

Anonymous Coward | about a year ago | (#45329067)

If it is the sort of thing the people developing themselves will have to be using (I don't mean same company, I mean literally the exact same people writing code has to use said code), then I think I have seen greater success. In other words, the new thing is born out of people writing their own out of a sense of frustration with what they do day to day. A critical facet for this is that such projects are 'skunkworks' and are never on the radar until they already are pretty successful. One thing making these things look good is that when they tank, usually only a handful of people even know it existed. They are developed at a 'when its ready' pace with annoyance driving progress forward in the absence of some management pressure to deliver.

If business executive says 'the cost for this software is too damn high' and then assembles a team to effectively complete with the vendor solution, that generally pans out poorly almost all the time.

Custom for core, not custom trashcan, word procssr (2)

raymorris (2726007) | about a year ago | (#45329665)

"exactly meets the needs of the business" is important for some things, a huge waste of time and money for others. Those "some things" where it matters are generally the core competency of the business - what sets them apart from competitors. Google search needs a database that exactly meets their needs for searching a huge database. MySQL won't meet their need. For 99% of businesses, building a custom database engine would be stupid - MySQL, MS SQL, or Oracle would meet not only their current needs, but also their future needs.

Future needs can be a huge hidden expense for custom work; you've saddled the company with a requirement to build 2.0, 3,0, etc. on down the road if your business is built on something custom. So you should ask yourself "does the next company down the block have a similar need as we do?" If so, you and the company down the block should probably be sharing the development cost by both buying the same off-the-shelf software. You don't custom design your own trash cans, and most software is the same - yours should be about the same as the other guy uses.

If off-the-shelf software provides 95% of what you need but you need 5% custom, that's where FOSS is a perfect fit.
You get 95% of it done, tested and ready to go, for free, and you just develop the 5% that you need special.

Re:A risky gamble (0)

Anonymous Coward | about a year ago | (#45329819)

"Done Right" it still requires a dedicated IT staff and perpetual payments to SAP. Why would any large corporation tolerate such an financial drain?

Re:A risky gamble (2)

Lumpy (12016) | about a year ago | (#45329865)

The trick is to tell the CIO of the company that is your customer that the price and deadline time doubles every single time they make changes. The trick is to get an accurate scope and then a project manager that will tell the customer NO! in a way that they understand, I.E. excessively high prices and they sign a paper that the deadline is ok to ignore. Suddenly that feature that they dreamed up in a meeting is not so important anymore. If it's really important then they will be OK with letting the system solidify and then start a new project to add it.

Software is 100% identical to Construction. you can not add a new Solarium in the middle of it after construction is 80% complete, et most software companies dont have the balls to tell the customer, "It will cost you an additional $22,000,000 at this point to add that and we have to throw away everything and start over.

The ones that do are the ones that are successful.

Re:A risky gamble (2)

Nerdfest (867930) | about a year ago | (#45328953)

There's usually very good reasons it goes wrong. If they tried re-writing SAP, tehy would have as well. I would guess they had very clear specifications for what they needed, and implemented only that, ideally in a concise maintainable well. Bad specs and scope creep kill most projects like this, yet people rarely seem to learn from past mistakes. They're far more likely skilled than lucky.

Re:A risky gamble (1)

Nerdfest (867930) | about a year ago | (#45328997)

.. also, you're completely correct that he should have been warned, although more about the common mistakes rather than the rarity of success, in my opinion.

Mod parent up. (2)

khasim (1285) | about a year ago | (#45329561)

In my experience, the biggest problem is when the CIO is not allowed to refuse requests. Once that is cleared (and the CIO is competent) then projects get finished on time and on budget.

In this case, it sounds like Elon had a lot of confidence in Jay's ability as CIO.

Re:A risky gamble (2)

mwvdlee (775178) | about a year ago | (#45328969)

The problem is, with solutions like SAP, it's also over budget and under spec.
Atleast with homebrew you have a change to ever reach spec and you don't have to spend the same budget again every next year.

Re:A risky gamble (1)

girlintraining (1395911) | about a year ago | (#45329041)

Atleast with homebrew you have a change to ever reach spec and you don't have to spend the same budget again every next year.

In other news, some people believe patching and bug hunting is free and that software never needs modification once installed. There will never be a support cost of any kind.

Re:A risky gamble (1)

Aighearach (97333) | about a year ago | (#45329297)

So you're implying that if you buy it, the support will be free? I thought the support was the most expensive thing. An in-house tool with only the features your company uses might have much lower support cost. You can also respond to support requests by modifying the feature to make it more clear; and you can do that quickly.

Re:A risky gamble (1)

h4rr4r (612664) | about a year ago | (#45329405)

So SAP support is cheap or free?

To make these claims you must be an SAP integrator/sales person.

I keep warning you and you keep laughing... (1)

Thud457 (234763) | about a year ago | (#45328975)

You don't get ahead in SPEKTOR by saying "no" to Hank Scorpio. You get fed to the sharks.

Re:I keep warning you and you keep laughing... (1)

girlintraining (1395911) | about a year ago | (#45329089)

You don't get ahead in SPEKTOR by saying "no" to Hank Scorpio. You get fed to the sharks.

You're referencing a character who first appeared on the Simpsons in the 90s... before SAP software as a class even existed. I believe this reference is so damn obscure that only some hipster would recognize it without googling for it. And as for SPEKTOR... Google has nothing. So who knows...

Re:I keep warning you and you keep laughing... (1)

Scottingham (2036128) | about a year ago | (#45329175)

Booo! The only Simpsons worth knowing is the 90s Simpsons, after about 2001 they were a husk of what they once were. Further, that is one of the best episodes from the series!

GiT, I normally love your insightful comments. Not sure how knowing episodes from a 90s cartoon is 'hip', but I'll take it! If you haven't seen the episode yourself, I highly recommend it.

Re:A risky gamble (0)

Anonymous Coward | about a year ago | (#45329003)

Many, if not most, IT initiatives fail. Period.

Re:A risky gamble (1)

Anonymous Coward | about a year ago | (#45329073)

You must have little experience with SAP. To stick with SAP is a sure loser. Building your own backend, at least you have a chance for your system to match your business process instead of you having to twist your business around to fit it. SAP is built to accommodate multiple industries and adds multiple steps to any one particular industry because of it. Steps that often require manual data entry or adjustments. My former CEO crowed it was "The Cadilac System" and spent millions on it. What a friken waste.. I will never work for a company that uses SAP again. There is a reason Walmart, Amazon, and a few other large MULTI BILLION DOLLAR companies " roll there own. They need a system that works.

Re:A risky gamble (1)

paiute (550198) | about a year ago | (#45329223)

My former CEO crowed it was "The Cadilac System" and spent millions on it. What a friken waste..

My former employer spent $10 million and counting on an SAP upgrade. I wondered if we went back to using index cards if we could ever be $10 million less efficient.

Re:A risky gamble (1)

fatphil (181876) | about a year ago | (#45329733)

My former employer used home-brewed tools. I wish I hadn't read this story, as I was just starting to forget the daily brain-rape that I had to endure. This has set me back weeks. Index cards would have been more effective, certainly.

Re:A risky gamble (1)

rsborg (111459) | about a year ago | (#45329103)

Many, if not most, IT initiatives with homebrew tech fails.

s/with homebrew tech//

Failure is the default for IT projects - last I heard it was 80% failure rate - most of this is due to unrealistic expectations, newbies billed as "senior" devs, and a project management methodology steeped in anti-patterns [1]. None of this is more prevalent in home-brew over vendor-supplied projects, in fact I'd say it's more likely the other way around.

[1] http://en.wikipedia.org/wiki/Anti-pattern#Project_management [wikipedia.org]

Re:A risky gamble (0)

Anonymous Coward | about a year ago | (#45329121)

Homebrew tech fails not because it's homebrew, but because of bad design practice. (Which is caused by any number of factors from inexperience to bad management to politics) Elon has created the sort of company that tends to do things correctly and design seems to be one of their strong points.

This is also SAP we're talking about. Faced with a SAP upgrade, I'd be more inclined to migrate to a pile of unorganized post it notes carelessly thrown in to old filing cabinets in the janitor's closet.

Re:A risky gamble (1)

Anonymous Coward | about a year ago | (#45329149)

My experience dictacts that it is not always over budget and under spec. However, as developers come and go, undocumented bugs and problems start cropping up. No thought is given to long term maintenance and bug fixes. You end up with needed developers to rewrite most of it in a few years when there is no one left to understand all the parts and pieces.

Re:A risky gamble (1)

Aighearach (97333) | about a year ago | (#45329333)

The same as any other equipment, if you aren't maintaining it consistently, in a few years when a part breaks and a mechanic finally opens it up, it is a rusted mess and you have to replace the whole thingamajig.

Re:A risky gamble (1)

CastrTroy (595695) | about a year ago | (#45329181)

Considering he had 25 people working on it. If each of those 25 people cost him $100,000 a year (salary and other related expenses), and they worked for 4 months on the project, then it cost him over $800,000 to implement the system. Although as others alluded to, I'm sure you could get a SAP system that would cost as much, and probably take as long to implement. It's not like MS Office, where you can just install it, and have it do everything it was meant to do. It would have been a big project either way. I wonder what the track record is like for SAP implementations going over-budget, past-schedule, or not doing what they need to do?

Re:A risky gamble (0)

Anonymous Coward | about a year ago | (#45329359)

someone i know who was unlucky enough to be stuck with it, said that it takes a year or more to get it configured and tested and whatever for your environment. and its the worst piece of junk software he has ever worked with.

there is an article from years back how AT&T spent millions of $$$ and months of coding and it was a failure and created a lot of problems

Re:A risky gamble (2)

h4rr4r (612664) | about a year ago | (#45329435)

Where would you find an SAP system that cheap?
There is no way one could be rolled out in 4 months.

I have never seen one that did not go over budget and past schedule, nor did what they wanted on launch day. I have not seen that many, but enough to guess that is the common outcome.

Re:A risky gamble (2, Informative)

m2pc (546641) | about a year ago | (#45329209)

We just went through this exact same exercise at the company I work for. When our antiquated, poorly-designed MRP system started causing too many headaches, we carefully counted the cost of moving to something like Salesforce.com or SAP, but ultimately ended up writing out own system from scratch. After running the two systems in parallel for 6 months to ensure the new system had data integrity we were comfortable with, we cut it off. Having just closed our first month "live" on the new system, I must say it's a real breath of fresh air for both the IS staff and the rest of the company. Gone are the days waiting for the slow moving MRP company to update their slow system to add features or fix bugs for us. Our hands were tied with the old system, and now the door is open to all sorts of possibilities. People are constantly saying "wow, we can do xyz now!" or "this wasn't even possible before with the old system". The daily complaints about the old system have been replaced with daily feature requests and positive comments.

The small team that built it remains on staff, and if something doesn't work, we fix it. If someone requests a feature that makes sense to the overall design goal, we sketch it out, schedule it, and implement it. We carefully weigh everyone's feature requests and implement only those that make sense for the overall "greater good" of the system. That way we keep feature creep down while building something that helps people get their job done faster. In the time between bug fixes and feature request, we are constantly polishing the system to make it more efficient. We now have a DEV environment where we can test out new ideas and features and release them to production only when they are ready.

Since we built ours with FOSS technologies, it's been a joy to integrate with our other trading partners (suppliers, our web store shopping cart, etc). The money we are saving on not having to pay for licensing costs (recurring yearly, never ending), we have invested in hardware and infrastructure to run the new system.

Perhaps the biggest benefit is when the system is released, the company will have a team on staff that knows the system inside and out, because they built it.

I would highly recommend any company considering buying an out-of-the-box ERP system to consider having an in-house team build them a custom solution. With the right group of developers, it can be a really rewarding experience for everyone!

Re:A risky gamble (1)

Anonymous Coward | about a year ago | (#45329519)

same where i work, except our is over a decade old

the dev teams build out small feature requests and bug fixes and release weekly. impossible with COTS software

Re:A risky gamble (2)

Kookus (653170) | about a year ago | (#45329381)

I can play the same game...
Many, if not most, IT initiatives with homebrew tech succeed. It's hurts when it doesn't pays off, but almost always it is under budget and satisfies the unique requirements of the business. If the CEO got unlucky, too bad for him, but his CIO shouldn't be sitting in the big chair if he didn't at least recommend doing it in house.

Unfortunately statements like these are easy to reword the exact opposite and not sound crazy. If you look at Gartner's statistics, they have a pretty even split between successful and failed implementations. From my experience, the outcome is completely dependent on the personnel. If you get people that are intelligent and want it to succeed in leadership roles (and they get along with each other), you'll have a lot better chance than having people who are coming for a huge paycheck and flying home on a Thursday afternoon.

Since Tesla probably has a pretty intelligent staff, I'm not surprised that they would succeed.

Re:A risky gamble (2)

sl4shd0rk (755837) | about a year ago | (#45329383)

Many, if not most, IT initiatives with homebrew tech fails.

I've seen $15k home-brewed storage solutions outpace $50k vended ones as well as $2500 servers outperform $20k ones. Those home-brews rely on talented in-house labor however, so if you can't keep the good employees around, you had better go the $50k route. Oh, don't forget the $4500/year maintenance contract and 3-5 day tier 1 support callbacks from people with such thick accents the interpreter needs an interpreter. That's not fail though because it's a purchased product amiright?

Re:A risky gamble (1)

NatasRevol (731260) | about a year ago | (#45329541)

I don't think you're counting the $1-200k salary of that in-house labor.

Re:A risky gamble (1)

pspahn (1175617) | about a year ago | (#45329827)

You know there are bright people out there who are willing to work for less money with the understanding that the job itself is more enjoyable and there are rewards down the road.

Not saying any company can just find these people, but they do exist.

In my case, I work for the family business, otherwise it would be nigh impossible for them to hire a developer of my skill level while still paying them the same *relative* peanuts I get. The reward is in knowing I am improving the business in a very cost-effective manner, and that these efforts will pay off down the line when our revenue doubles because of my work.

Re:A risky gamble (1)

NatasRevol (731260) | about a year ago | (#45330017)

talented in-house labor is expensive. Otherwise, it doesn't stay in-house. Those ARE the rewards down the road.

Re:A risky gamble (4, Interesting)

Anonymous Coward | about a year ago | (#45329387)

Yep a guy who built his first tech company at 24 got lucky
what does a founder of paypal know about large scale software projects compared to arm chair CIO on slashdot

Re:A risky gamble (1)

Tridus (79566) | about a year ago | (#45329413)

Considering the high cost, higher failure rate, and even higher odds of going overbudget on trying to get SAP to do what you want, I'm not even remotely convinced it was a gamble. If you already have a team in place, this is the less risky way to go because you're only going to build what you need and you're not dependent on a third party to maybe one day make it work if you throw enough consultant money at them.

Re:A risky gamble (0)

Anonymous Coward | about a year ago | (#45329553)

good point, but we're not talking about your average software engineers here... these guys are top talent, hence the reduced risk of the decision.

I always LOVE to hear "DIY" stories (1)

Chas (5144) | about a year ago | (#45329899)

They're always good for a laugh.

We've had a client who, for years, has been threatening to move off to his own little CRM system that one of his in-house techs cooked up. He does this, mostly, because he thinks he's going to frighten us into giving him a free upgrade of his current software.

We always make sure to mute the phone when he does this, so he doesn't hear us laughing at him.

His tech's solution is basically a Fox Pro front end on an excel spreadsheet.
And it doesn't even do a tenth of what the client needs, let alone come close to the functionality of his current package.

Sure, Musk can actually afford to hire a group of REAL programmers. But, still, they're reinventing the wheel, and there's no guarantee the system's going to grow with the company.

Less risky for Tesla specifically? (1)

swb (14022) | about a year ago | (#45330045)

I can see the risk aspect to this at a 'normal' company with the typical suit and tie CEO who rose up from sales or marketing. Somehow, though, Tesla probably has some things going for it it that other businesses don't.

For one, a CEO who has built an Internet software based business in an era where you built it yourself because there was nothing else to base it on. The entire company and product they are producing is unlike anything else out there and a lot of what they produce they have to produce themselves from scratch, so there's a culture of "do it yourself" already in place.

Given the nature of the product, I would doubt there are many employees at Tesla, especially in the technology side of the business, who are there solely because it is a paycheck and there's free coffee. Most of the employees are probably there at least partly because of some belief in the product itself or the (potentially) environmentally transformative nature of the product, which makes them likely to be more highly motivated to see the company succeed than the typical employee who is motivated more by a sense of career achievement, compensation, etc.

I would also bet the employees in any technology-oriented capacity at the company are smarter than the average bear. Given Musk's drive and background, the technology hiring standards and internal respect for IT are probably much higher at Tesla, than at a company that makes run of the mill widgets.

So while I agree that home-brew systems have a better-than-average chance of failure at a typical company because of tech-ignorant management, IT staffs of average ability and motivation, Tesla has a lot of things going for it that make it more likely they will succeed.

article (5, Informative)

Anonymous Coward | about a year ago | (#45328943)

By Rachael King

Reporter

Half Moon Bay, Calif. — Leave it to Elon Musk to buck conventional wisdom. When Tesla Motors Inc.TSLA +7.29%, the Silicon Valley-based automaker he founded, needed to improve the backend software that runs its business, he decided not to upgrade the company’s software from SAP AGSAP.XE 0.00%. Instead, he told CIO Jay Vijayan to build it himself.

“Initially, I was very skeptical,” said Mr. Vijayan, Thursday, at Constellation Research Inc.’s Connected Enterprise Conference in Half Moon Bay, Calif. But, in the end, “Elon was right,” he said, adding that the new system gives his company the speed and agility it needs. His team built it in just four months.

Guus Schoonewille/AFP/Getty Images
A view of a Tesla car on an assembly line
Last year, Tesla was facing delivery delays of the all-electric Model S which it introduced on June 22, 2012. At the same time, Mr. Vijayan’s team of about 25 software engineers was working hard to build a system that could support ramped up production. The improved information technology systems are important for managing high volume production of the Model S, according to company filings. The system went live in July 2012.

Backend software, known as enterprise resource planning software, can make or break a company. SAP has become the world’s largest business software company by building incredibly complex software that can manage customers, suppliers, and the entire lifecycle of a product. SAP says that it is a leading provider of technology for the automobile industry, with nine out of the top 10 companies running SAP applications.

The software is widely used by other large companies as well. Hewlett-Packard Co., for example, uses SAP software to manage the operations needed to sell its printers, servers and PCs. H-P CIO Ramon Baez, also attending the conference, told CIO Journal that it operates at too large a scale to build its own custom enterprise resource planning software.

“You can shoot yourself in the foot if you don’t know what you’re doing,” said Mr. Vijayan. “You need the right team,” he said.

Yet, Mr. Vijayan was in a tough spot. It can take more than a year and millions of dollars to roll out SAP software because of all the integration required. For example, NTT Data is currently undergoing a two-year, $20 million enterprise resource planning consolidation. Tesla didn’t have the time needed to undertake such a project. By creating a custom software project, he was able to get it up and running quickly, partially because it didn’t need integration of disparate applications. Because Mr. Musk made a clear decision, it also helped Mr. Vijayan get immediate cooperation from business leaders.

Yet, there will likely be challenges ahead as Tesla grows. Building and running a lightweight enterprise resource planning system can be done when a company is relatively small but the problem is making it scale, Ben Haines, CIO at Box Inc. told CIO Journal.

“I’m super confident that it’s going to be able to scale very well,” said Mr. Vijayan. “It’s now one of the best systems we have.”

Re:article (4, Interesting)

spasm (79260) | about a year ago | (#45329607)

I like how they describe SAPs customers as an industry (automobiles) which struggles, and a specifc company (HP) which outright sucks. If correlation was causation I'd say buying SAP is how you destroy a company.

Building it is one thing (4, Insightful)

nightsweat (604367) | about a year ago | (#45328949)

Maintaining it another. One of the hardest things to do is keep up with tax and regulatory changes in your software. You have to be aware of a change before you can implement it.

Re:Building it is one thing (0)

Anonymous Coward | about a year ago | (#45329479)

Yeh a large public company has no in house finance expertise cause accounting and financial reporting requirements for a public company are trivial compared to tax changes.

Re:Building it is one thing (2)

aaarrrgggh (9205) | about a year ago | (#45329759)

We have come to the painful realization that project and financial accounting cannot effectively be done with the same software. It actually has better value for us to hire anothe bookkeeper and run our tax books in QuickBooks and project accounting in a fairly simple database. All the downsides of rolling your own still exist in a packaged solution; the real costs are in the customization.

In retrospect, rolling our own (even at contract rates of $135/hour) would have had a 3-year payback compared to the solution we went with. We could have even phased expansion of the system to keep the expenditure cash-flow positive. But, in the end it comes down to enterprise will and dedicating the resources required to identify needs, priorities, and what the future holds.

back to the good ole days (1)

Anonymous Coward | about a year ago | (#45328959)

When every organization did the same thing, had in-house staff to support it, and didn't have to bother with consultants. It can be a problem to keep track of all the different legal changes in the various locations though.

Re:back to the good ole days (2)

tgd (2822) | about a year ago | (#45329315)

When every organization did the same thing, had in-house staff to support it, and didn't have to bother with consultants. It can be a problem to keep track of all the different legal changes in the various locations though.

And hope, in 24 years, they've still got some geezers on the payroll who remember that old "Java" language from the early 21st century running on a crufty emulator no one can remember how to reinstall and can figure out all the places the engineers had said 4 bytes were plenty to hold a timestamp.

Re:back to the good ole days (1)

zarr (724629) | about a year ago | (#45329555)

Hey, that's my retirement plan!

To be fair, Java will generally yell at you if you try to assign a timestamp to an int.

Re:back to the good ole days (0)

Anonymous Coward | about a year ago | (#45329991)

That is why you plan and budget for redesigned in the future. You don't expect your hardware to last forever and people shouldn't expect their software to do so as well. Software itself doesn't degrade, but the requirements and environment around it changes. Too many businesses don't understand this.

Overly descriptive... (0)

Anonymous Coward | about a year ago | (#45329013)

Do we really need to qualify the Model S as "all-electic"? This is a story about Tesla Motors... of COURSE the car is all electric.

Re:Overly descriptive... (0)

Anonymous Coward | about a year ago | (#45329265)

I ordered mine with a 2-stroke model airplane engine to run the fan.

Menards (0)

Anonymous Coward | about a year ago | (#45329061)

Menards, the home improvement store chain, does a similar process.

If it is remotely possible, every piece of software is written in house. From scheduling, project management, even an FTP client was all written in house, and sucks.

They even used to alter the pinouts on RJ-45 Ethernet cable jacks to prevent "non-Menards" hardware from being connected to the networks at the stores. Nevermind that this required almost a full-time person to "make" the cables required for a nationwide chain, or that the cables they sold on the shelf wouldn't work in the store, it was MORE SECURE!

Does I run Linux? (2, Funny)

Anonymous Coward | about a year ago | (#45329085)

I bet it uses a beowulf cluster architecture. Just make sure some idiot from accounting doesn't spill a bowl of hot grits on the server. Even with a journaling filesystem like ext4, or the superior ReFS, hot grits can petrify most sys admin types.

I wish these Tesla folks the best of luck on this homebrew. In the end though the ROI and TCO will surely be much worse than a suitable off the shelf package from an established vendor like Microsoft or IBM. It may not matter, though, because Tesla will likely flameout and become the next Solyndra

Tough Decision (0)

Anonymous Coward | about a year ago | (#45329133)

Wow - that's why the CEOs make big bucks...tough decision...SAP, or build your own. Having used SAP, I would gladly farm the build out to a group of freshmen coders...chances are very high the product would be better anyway.

(PS - that's freshmen in high school)

Conventional Wisdom (1)

Anonymous Coward | about a year ago | (#45329239)

The conventional wisdom is to use packages for anything that's not unique to your business, and build anything that is critical to your company's success. If your company is extremely innovative (meaning that you're trying to innovate everywhere -- how teams are built, how they interact, who makes decisions, etc.) then you really have no choice but to build everything. That's the situation Musk is in. His company is fiddling with pretty much everything, hoping to invent the "company of the future." That _doesn't_ mean it's a good idea for every CIO to follow his path. In fact, for _most_ CIOs, this would be suicidal.

Context is everything.

Ehhhrrrr.... (0)

Anonymous Coward | about a year ago | (#45329271)

"Very fast, without using a gasoline motor"...?

One reason to replace IT is energy costs (1)

WillAffleckUW (858324) | about a year ago | (#45329353)

Most data centers are now looking at green servers, or extremely green servers, including DC power for blade farms, just as a cost-cutting measure.

It's like building a Tesla superhighway from Vancouver BC to San Diego CA with fast battery swap facilities so that you can actually drive an electric Tesla from one border to the next. People said it couldn't happen, but Tesla made it happen.

Btw, the Tesla that burned was just a few miles from here, but our news has lots of cars and trucks burning all the time - they're actually SAFER than gasoline cars.

not too surprising (1)

darue (2699381) | about a year ago | (#45329379)

but "enterprise" (aka Patronage Fiefdoms) prefer to spend big money on invoices from other "enterprises" rather than trust their own people to do anything. That way if anything goes wrong they can just blame the vendor, have someone to sue, etc. It's pathetic but we have a lot of pathological culture in our large organizations. Starting with them being run by people who don't know how to do jack shit but get hired as "executives".

4 months?? (0)

Anonymous Coward | about a year ago | (#45329547)

Does that include the time required to learn German?

In House Manufactering (2)

Kagato (116051) | about a year ago | (#45329651)

Tesla does a tremendous amount of the work in-house. This includes things like the class A metal stamping, battery packs and a slew of custom parts and electronics. Most auto makers warehouse pre-stamped body panels and parts. Tesla warehouses raw rolled steel and aluminum. They make the parts as needed. They have one of the most automated factories in the world so it's unlikely that an outside supplier would be able to do it cheaper.

While they do have a lot of things they get from other vendors, it's a fairly small list in comparison to most transportation manufacturers. In addition they have a relatively small number of products they make (including parts for other auto makers). Because of this they simply don't need SAP. It's a size and scope that you could do in-house. GM or Ford could never scrap their logistics suite and have a replacement in 4 months.

sap?! (0)

Anonymous Coward | about a year ago | (#45329703)

ANYTHING is better than SAP, so this doesnt mean much.

Oversell? (4, Insightful)

recharged95 (782975) | about a year ago | (#45330009)

Sure they built it in 4 months...
But likely spent the last 9 years figuring out why SAP was bad. Hence they knew what they wanted (by now)... Hire some good s/w developers and voila... you'll have a better system from the get-go. That's business systems 101: it's all about domain knowledge. Sure they built it in 4 months, but I see it took them 8.6 years to create it... by understanding why the SAP solution sucked and the experience on what worked and what didn't.

If they started from scratch with no SAP experience.... well I'm sure we'd see a different story. The same story as Oracle, MS, HP, IBM, and SAP (i.e. their in-house systems suck big time).

Now some new MBA graduate will disagree: now new systems can be built in 4 months, muck did it... then again...

25 s/w devs? (0)

Anonymous Coward | about a year ago | (#45330055)

At that rate in the valley, they just paid around 1.25million for that system... 25 devs sounds like a big time nowadays....

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?