5 ms·

* I'd love to see that as well * At the same time: - A LOT of companies are uncomfortable making some of this data SaaS / external. I'm not saying they're rig

* I'd love to see that as well * At the same time: - A LOT of companies are uncomfortable making some of this data SaaS / external. I'm not saying they're right, but it's there - A LOT of companies are unique, or strongly believe they're unique, and that they need bespoke / highly customized software. I'm not saying they're right... ;) - I'm a techie, so it's taken me a decade to realize that implementing a new backoffice suite by a consulting company is one third or less technical / IT project; and two thirds or more business process / transformation project. And the actual success / failure of these projects is almost entirely guided by the business transformation part. And when a company views ERP as a technical/IT project, it is most likely to not end well (small scale example: Sally in accounting refuses to change and insists that the new fancy software, on-prem or SaaS, do things the way she's done them for 2 decades in Excel, because that's "how their company does it"... no matter how inefficient or outdated they are. If you're seen as an IT project, it's your duty to accommodate Sally and now you're building the same thing over and over, compromising any value in your new ERP, SaaS or otherwise. If you're seen as business transformation project, you have some chance to make a difference and make things better...] - Therefore SaaS would reduce FAR less effort in ERP than many techies (including myself) feel. Basically, you'd still have a consulting company come in to (try) to do business transformation so your internal processes actually accept and match the SaaS processes; build interfaces; and then maintain and support. Disclosure/example: I'm in consulting part of IBM, and while I'm currently on a legacy ERP project, my colleagues in "Cloud/SaaS" (i.e. "let somebody else host it for you") side are no less busy than before. Mind you, they are on average providing higher value services, so that's a plus :)

jagged-chisel 7y ago
> companies are uncomfortable making some of this data SaaS / external SaaS can be on-premises. > Sally in accounting refuses to change The tools need to adapt to the user, the user shouldn't need to adapt to the tool. That said, if there are obvious efficiency gains (e.g. you can stop typing "COMPLETED" three hundred times a day and just click a button that fills the field for you; even better, the process marks it 'completed' once all the human verification has taken place) and the user is stubborn, well, maybe the tool should offer the efficient solution, allow the inefficient behavior, and log metrics on the whole thing. Management might take interest.
- NikolaNovak 7y ago
  >>SaaS can be on-premises. True; the distinction between SaaS and COTS becomes moot in practical terms then, and all of my comment still applies. >>The tools need to adapt to the user, the user shouldn't need to adapt to the tool. Again, that's: - True for an IT project whose goal is to support whatever the user is currently doing (and what many of us are trained to do / think in current IT paradigm). - Not True for a business transformation project whose goal is to change business processes for the better - and, basically incidentally, deliver a COTS ERP to support them through an IT portion of the project. We are not talking about where the button is or how many times it takes to click or what the icon looks like. We are talking fundamental business processes and workflow, which are core to how a business operates internally. For business processes which are company's core business, presumably they have them figured out. That's great, and IT should support them. For back-office ERP, this is not your company's core business; you're probably not a special snowflake; and the market's average/best practices are likely miles ahead of your legacy over-complicated business processes. YOU need to change if you want to reap the benefits of shiny expensive new software. There is extremely limited point in implementing a new back-office ERP (HR, Financials, CRM, EPM, etc) if you're not willing to approach it as BT project; radically change how you do things; and expect a shiny new tool to make you more competitive automagically without your processes and maybe even culture/habits changing. My fundamental point remains: what the big consulting companies do with ERP / backoffice implementation (when done right) are primarily BT projects, and incidentally involve IT implementations; and treating them as IT projects, whether that's Sally in accounting refusing to change or Bob the developer accommodating Sally thinking it's the right thing to do, will cause them to fail. (generalizations and oversimplifications abound in above statement; but it really takes a very very large and repeated application of a mental sledgehammer to dislodge some universally-good but specifically-counterproductive ideas and habits from the ERP space)
  - ghaff 7y ago
    Quite a few years ago, I was at a very small company and we made the decision to move from hosting our own Microsoft Exchange to Gmail--partly for cost reasons and partly because we had had a couple of serious mail outages. A couple of people at the time were really unhappy about the change because there were some differences, at least at the time, in the ability to create nested folders/labels like they were accustomed to doing in Exchange. Basically, Gmail messed up the organizational scheme they were accustomed to for client and contracts. They were basically told to deal with it but the point is that even when going to some standard SaaS makes sense, people are very resistant to making changes in their standard tools.
polygotdomain 7y ago
>implementing a new backoffice suite by a consulting company is one third or less technical / IT project; and two thirds or more business process / transformation project. And the actual success / failure of these projects is almost entirely guided by the business transformation part. This 1000%. There's so much institutional friction with these projects for so many reasons; some of them political, some of them interpersonal, some of them just because someone doesn't want to. So many of these projects fail because people just don't want to work towards the goal, or simply do as little as possible and things move slower than molasses. People don't want or care to change their processes. They do things that way because they've always done things that way. They see tools not as a way to get more done or be efficient, but as something that's "moving their cheese" and they don't like it. It doesn't matter how overworked they are by remedial tasks that could be automated, until you show them everything finished, end-to-end, working flawlessly, they won't be interested in the slightest. The sad thing is that if there were some strong executive leadership behind these projects and they saw it as a positive thing, there could be better traction and better results. Instead, most execs look at these projects as mundane details and hand them off to whatever sad middle manager is going to take the heat for the project going south. The result is no teeth behind the initiative which even further exacerbates the issue of people not caring or lifting a finger.
- JohnFen 7y ago
  > They see tools not as a way to get more done or be efficient, but as something that's "moving their cheese" and they don't like it. In all fairness, this perception of tools is often entirely rational. Changing workflows incurs a high cost, and any new tool must supply a benefit in excess of that cost. If it doesn't, then opposing the new tool can be the correct stance. And in my experience, at least half of the time, the new tools do not provide sufficient benefit.
  - IggleSniggle 7y ago
    Exactly. There's endless tooling out there, and you can contort software to whatever process. Some of tools make claims that, if trivial to implement, would provide huge huge benefits. Unfortunately, there's a cost to learning a new tool, and then to implementing its use. Since you don't know the tool yet, you can only make educated guesses as to whether it will be easy or hard to learn, easy or hard to implement, make your process better or worse, help sell your product or make you more efficient, etc. You can't know for sure (unless it seems so much like something you already DO understand, and in that case, why would you use someone else's tool)? And that's only for yourself. I'm not saying you shouldn't try new tools. To the contrary. It's just hard to know which ones are the right ones for your organization. Hence cargo-culting of tools that may or may not be a step backwards for your organization, or have all kinds of hidden-costs that are difficult or even impossible to foresee.
jariel 7y ago
" that implementing a new backoffice suite by a consulting company is one third or less technical / IT project; and two thirds or more business process / transformation project" It's at least 50% sales.
- NikolaNovak 7y ago
  A cynical comment that has some roots in truth, but really needs some metrics defined to be useful :-) By time spent? Not on anything but the tiniest projects which are likely to be loss-leaders anyway. By value added? For consulting company, sure, that's one way to look at it; for the customer, probably not :P For the purposes of my post, pre-sales/sales/RFP/whatever were assumed to be done prior to start of implementation. Though I will agree that how ERP project is pitched/sold may well have an impact on the delivery: - the IT vs BT categorization per above is likely implicitly or explicitly setup at these early stages - who the stakeholders/champions are / who signed off on purchase and why - the CIO because their previous product is EOL? The VP of functional department (HR/Finance/etc) because they want to realize value in changing processes? Etc - are the timelines and deliverables reasonable - is the goal / value realized / ROI well defined and agreed - are the requirements and scope well defined and agreed - etc (edited to change nested brackets into bullet points :P )
  - jariel 7y ago
    I'm not being cynical. The lifeblood of major consulting is the sales life cycle, which includes branding, relationship building. Lobbying costs. Responding to RFPs. Advertising. Trade shows. Expensive offices (to give the appearance of credibility). White papers. Paying off Gartner etc. so they put you in the 'good quadrant'. Partners at some firms spend nights a week having people in the industry over for dinner, nice wine etc..
    - arethuza 7y ago
      Having been on the buying side of large enterprise projects (up to $50 million) I was surprised at the number of vendors who simply look at a very small outline of the project and decide not to get involved. Later on, back on the selling side, I now appreciate that "qualifying out" opportunities is definitely a critical activity otherwise you well spend huge amounts of money chasing stuff that you probably won't win or, worse, win and make a loss on.

jagged-chisel 7y ago

> companies are uncomfortable making some of this data SaaS / external SaaS can be on-premises. > Sally in accounting refuses to change The tools need to adapt to the user, the user shouldn't need to adapt to the tool. That said, if there are obvious efficiency gains (e.g. you can stop typing "COMPLETED" three hundred times a day and just click a button that fills the field for you; even better, the process marks it 'completed' once all the human verification has taken place) and the user is stubborn, well, maybe the tool should offer the efficient solution, allow the inefficient behavior, and log metrics on the whole thing. Management might take interest.

NikolaNovak 7y ago
>>SaaS can be on-premises. True; the distinction between SaaS and COTS becomes moot in practical terms then, and all of my comment still applies. >>The tools need to adapt to the user, the user shouldn't need to adapt to the tool. Again, that's: - True for an IT project whose goal is to support whatever the user is currently doing (and what many of us are trained to do / think in current IT paradigm). - Not True for a business transformation project whose goal is to change business processes for the better - and, basically incidentally, deliver a COTS ERP to support them through an IT portion of the project. We are not talking about where the button is or how many times it takes to click or what the icon looks like. We are talking fundamental business processes and workflow, which are core to how a business operates internally. For business processes which are company's core business, presumably they have them figured out. That's great, and IT should support them. For back-office ERP, this is not your company's core business; you're probably not a special snowflake; and the market's average/best practices are likely miles ahead of your legacy over-complicated business processes. YOU need to change if you want to reap the benefits of shiny expensive new software. There is extremely limited point in implementing a new back-office ERP (HR, Financials, CRM, EPM, etc) if you're not willing to approach it as BT project; radically change how you do things; and expect a shiny new tool to make you more competitive automagically without your processes and maybe even culture/habits changing. My fundamental point remains: what the big consulting companies do with ERP / backoffice implementation (when done right) are primarily BT projects, and incidentally involve IT implementations; and treating them as IT projects, whether that's Sally in accounting refusing to change or Bob the developer accommodating Sally thinking it's the right thing to do, will cause them to fail. (generalizations and oversimplifications abound in above statement; but it really takes a very very large and repeated application of a mental sledgehammer to dislodge some universally-good but specifically-counterproductive ideas and habits from the ERP space)
- ghaff 7y ago
  Quite a few years ago, I was at a very small company and we made the decision to move from hosting our own Microsoft Exchange to Gmail--partly for cost reasons and partly because we had had a couple of serious mail outages. A couple of people at the time were really unhappy about the change because there were some differences, at least at the time, in the ability to create nested folders/labels like they were accustomed to doing in Exchange. Basically, Gmail messed up the organizational scheme they were accustomed to for client and contracts. They were basically told to deal with it but the point is that even when going to some standard SaaS makes sense, people are very resistant to making changes in their standard tools.

polygotdomain 7y ago

>implementing a new backoffice suite by a consulting company is one third or less technical / IT project; and two thirds or more business process / transformation project. And the actual success / failure of these projects is almost entirely guided by the business transformation part. This 1000%. There's so much institutional friction with these projects for so many reasons; some of them political, some of them interpersonal, some of them just because someone doesn't want to. So many of these projects fail because people just don't want to work towards the goal, or simply do as little as possible and things move slower than molasses. People don't want or care to change their processes. They do things that way because they've always done things that way. They see tools not as a way to get more done or be efficient, but as something that's "moving their cheese" and they don't like it. It doesn't matter how overworked they are by remedial tasks that could be automated, until you show them everything finished, end-to-end, working flawlessly, they won't be interested in the slightest. The sad thing is that if there were some strong executive leadership behind these projects and they saw it as a positive thing, there could be better traction and better results. Instead, most execs look at these projects as mundane details and hand them off to whatever sad middle manager is going to take the heat for the project going south. The result is no teeth behind the initiative which even further exacerbates the issue of people not caring or lifting a finger.

JohnFen 7y ago
> They see tools not as a way to get more done or be efficient, but as something that's "moving their cheese" and they don't like it. In all fairness, this perception of tools is often entirely rational. Changing workflows incurs a high cost, and any new tool must supply a benefit in excess of that cost. If it doesn't, then opposing the new tool can be the correct stance. And in my experience, at least half of the time, the new tools do not provide sufficient benefit.
- IggleSniggle 7y ago
  Exactly. There's endless tooling out there, and you can contort software to whatever process. Some of tools make claims that, if trivial to implement, would provide huge huge benefits. Unfortunately, there's a cost to learning a new tool, and then to implementing its use. Since you don't know the tool yet, you can only make educated guesses as to whether it will be easy or hard to learn, easy or hard to implement, make your process better or worse, help sell your product or make you more efficient, etc. You can't know for sure (unless it seems so much like something you already DO understand, and in that case, why would you use someone else's tool)? And that's only for yourself. I'm not saying you shouldn't try new tools. To the contrary. It's just hard to know which ones are the right ones for your organization. Hence cargo-culting of tools that may or may not be a step backwards for your organization, or have all kinds of hidden-costs that are difficult or even impossible to foresee.

jariel 7y ago

" that implementing a new backoffice suite by a consulting company is one third or less technical / IT project; and two thirds or more business process / transformation project" It's at least 50% sales.

NikolaNovak 7y ago
A cynical comment that has some roots in truth, but really needs some metrics defined to be useful :-) By time spent? Not on anything but the tiniest projects which are likely to be loss-leaders anyway. By value added? For consulting company, sure, that's one way to look at it; for the customer, probably not :P For the purposes of my post, pre-sales/sales/RFP/whatever were assumed to be done prior to start of implementation. Though I will agree that how ERP project is pitched/sold may well have an impact on the delivery: - the IT vs BT categorization per above is likely implicitly or explicitly setup at these early stages - who the stakeholders/champions are / who signed off on purchase and why - the CIO because their previous product is EOL? The VP of functional department (HR/Finance/etc) because they want to realize value in changing processes? Etc - are the timelines and deliverables reasonable - is the goal / value realized / ROI well defined and agreed - are the requirements and scope well defined and agreed - etc (edited to change nested brackets into bullet points :P )
- jariel 7y ago
  I'm not being cynical. The lifeblood of major consulting is the sales life cycle, which includes branding, relationship building. Lobbying costs. Responding to RFPs. Advertising. Trade shows. Expensive offices (to give the appearance of credibility). White papers. Paying off Gartner etc. so they put you in the 'good quadrant'. Partners at some firms spend nights a week having people in the industry over for dinner, nice wine etc..
  - arethuza 7y ago
    Having been on the buying side of large enterprise projects (up to $50 million) I was surprised at the number of vendors who simply look at a very small outline of the project and decide not to get involved. Later on, back on the selling side, I now appreciate that "qualifying out" opportunities is definitely a critical activity otherwise you well spend huge amounts of money chasing stuff that you probably won't win or, worse, win and make a loss on.