Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Businesses IT

How Elon Musk Approaches IT At Tesla 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."
This discussion has been archived. No new comments can be posted.

How Elon Musk Approaches IT At Tesla

Comments Filter:
  • SAP (Score:5, Funny)

    by Anonymous Coward on Monday November 04, 2013 @03:34PM (#45328841)

    S - end
    A - nother
    P - ayment

    • Re:SAP (Score:5, Funny)

      by Reverand Dave ( 1959652 ) on Monday November 04, 2013 @04:07PM (#45329267)
      We always called it Sorry Ass Program.
    • Re:SAP (Score:5, Insightful)

      by jellomizer ( 103300 ) on Monday November 04, 2013 @05:06PM (#45330095)

      The issues that a lot of people really don't get.
      Products like SAP are great if you do your business the same way as everyone else.
      That said. Businesses all tend to run differently thus SAP becomes more of a problem then it helps.
      However Suits like the Term Enterprise software and signing big checks, it makes them feel like they are running a big company, and it feels good to know they are running an Enterprise standard software, they probably have been burned by the single developer tool that becomes unmaintainable after he leaves so they jump to a full commercial system.

      However for the most part if you have a good development team on staff, you usually can make something better, faster and cheaper than SAP. Because you can focus on what is important and leave out the extra stuff. But as I stated your company will need a development team, not a single guy who is the lone coder.

      • It's who's selling the solution. The sales people cater to the execs/management and know the buzzwords that make the all tingly.

        If the suggested solution comes from IT/Bottom up it's usually a lot of details they can't grasp and don't really care about.

        • From what I've experienced the SAP sales teams usually include a hot blonde who the executives won't turn down for a business dinner.

      • ...that if you do something like this, numerous ISO standards and other auditing bodies follow a formal ERP methodology. There are also issues of compliance with GAAP (Generally Accepted Accounting Principals) and most assuredly, the IRS.

        People "run there business like everyone else" for a reason.

      • The issues that a lot of people really don't get.
        Products like SAP are great if you do your business the same way as everyone else.

        Exactly. That's why SAP's modules for areas like Human Resources and Accounting work decently well, but other areas that are industry or company specific cause more problems than they solve.

      • Products like SAP are great if you do your business the same way as everyone else.

        No. No they aren't. At least, not if they are SAP. SAP is a motherbitch. It crops up in industries where it has no business at all, like in casino gaming management. And it needs to be set afire.

    • S - Software A - Against P - Productivity
    • sap
      [sap] noun, verb, sapped, sapping.
      noun
      1. the juice or vital circulating fluid of a plant, especially of a woody plant.
      2. any vital body fluid.
      3. energy; vitality.
      4. sapwood.
      5. Slang. a fool; dupe.
      As in the person who buys this software product
  • No article (Score:5, Informative)

    by Anonymous Coward on Monday November 04, 2013 @03:37PM (#45328873)

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

    • by s.petry ( 762400 )

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

  • A risky gamble (Score:2, Informative)

    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 (Score:5, Insightful)

      by gaudior ( 113467 ) <{marktjohns} {at} {gmail.com}> on Monday November 04, 2013 @03:42PM (#45328935) Homepage

      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 (Score:5, Insightful)

      by nbvb ( 32836 ) on Monday November 04, 2013 @03:42PM (#45328951) Journal

      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.

      • 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 (Score:4, Insightful)

          by jd2112 ( 1535857 ) on Monday November 04, 2013 @04:02PM (#45329199)
          Risk vs. reward. What have you gained from not wearing seatbelts other than perhaps a few less wrinkles on your clothes?
          • by LoRdTAW ( 99712 )

            "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 (Score:4, Insightful)

            by girlintraining ( 1395911 ) on Monday November 04, 2013 @04:35PM (#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.

            • by cusco ( 717999 )

              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.

              • 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.

                The "other" hand? You're going to take something that's inherently complex and risky even when done professionally by a company with hundreds of developers... and then roll your own? And that's less of a risk in your world?

            • I have learned that most people are utter shit at estimating risk

              I will see and raise you. I would go as far as to say that everyone sucks at risk management. The fact is that even the most rational of us are driven by base instincts and our habits more than rational thought. And when you get a group of us humans together, the risk management gets even worse. Decisions get made out of fear more than rational thought.

        • A seat belt isn't even necessarily to protect yourself but to protect others from you. So I'm not sure that analogy works. Also you'd have a point if there was clear proof that going with SAP or any other buy-in clearly worked better. That is far from the truth. I've seen it go wrong and come in late numerous times. Then when shit goes wrong it can't be fixed asap because there's zero talent within the company and you pay through the nose to get someone to fix it for you.
      • "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

      • by Lumpy ( 12016 )

        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

      • 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.

        The done right is the tricky part. And that requires actually knowing the needs of the business.
        Most execs 'need' SAP because they want an enterprise system. They don't talk about buying it to fix a particular problem, then spend more exec time analyzing the problem to decide what a profitable fix would look like. Businesses that actually do that don't have too much of a problem implementing SAP (because they do it bit by bit) nor do they have much problem writing a solution in-house.

        But most folks don't

    • 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.

      • .. 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.

      • 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.

    • by mwvdlee ( 775178 )

      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.

      • 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.

        • 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.

        • by h4rr4r ( 612664 )

          So SAP support is cheap or free?

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

    • You don't get ahead in SPEKTOR by saying "no" to Hank Scorpio. You get fed to the sharks.
    • by rsborg ( 111459 )

      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]

    • 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
      • by h4rr4r ( 612664 )

        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: (Score:2, Informative)

      by m2pc ( 546641 )

      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 sa

    • by Kookus ( 653170 )

      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 ev

    • 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?

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

        • by pspahn ( 1175617 )

          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-effect

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

    • Re:A risky gamble (Score:4, Interesting)

      by Anonymous Coward on Monday November 04, 2013 @04:16PM (#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

    • by Tridus ( 79566 )

      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.

    • 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 clie

    • 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 themse

    • Many, if not most, IT initiatives with homebrew tech fails. It's nice when it pays off...

      Most SAP initiatives also fail. Most small businesses fail at business within two years.

    • At a guess he realised it's better to treat your employees well so you can get good talent that does a good job. That and what they really need is probably a fraction of what SAP can do so it shouldn't take that long.

      Only a consultant would think that it's better to outsource than to hire competent talent and treat them well.
  • article (Score:5, Informative)

    by Anonymous Coward on Monday November 04, 2013 @03:42PM (#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.”

  • by nightsweat ( 604367 ) on Monday November 04, 2013 @03:42PM (#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.
    • 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

  • by Anonymous Coward

    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 flam

  • by Kagato ( 116051 ) on Monday November 04, 2013 @04:34PM (#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.

  • Oversell? (Score:5, Insightful)

    by recharged95 ( 782975 ) on Monday November 04, 2013 @05:00PM (#45330009) Journal

    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...

  • by Udo Schmitz ( 738216 ) on Monday November 04, 2013 @06:16PM (#45330791) Journal

    This sentence from the summary is just great:

    “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.”

    Someone should make a poster from it.

  • Social ROI (Score:3, Informative)

    by Ryan Poland ( 3420345 ) on Monday November 04, 2013 @06:34PM (#45330917)
    To me one of the 'hidden' returns on a gamble & investment like Tesla has made is a social one. I can't even imagine the pride the IT team at Tesla feels to go from resetting user passwords to bragging to their friends that they built from scratch an operating ERP system. In a podcast Jay Vijayan mentions that the upfront costs were similar in analysis, but the later savings in cost can be 're-invested' into the people and organization. To me it seems a no-brainer to embark on this investment, since the returned value is something that can't be reasonably purchased. (IMHO) podcast here: http://www.metisstrategy.com/interview/jay-vijayan/ [metisstrategy.com] -Ryan

On the eighth day, God created FORTRAN.

Working...