3 ms·

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

> 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.
  - NikolaNovak 7y ago
    My mind thinks hierarchically in everything I do so I understand that Google's "Search, don't sort" is difficult to adopt to. (Note, FWIW, though I think we're on the same page - the "business processes" I'm talking about in relation to ERP are less interface/program-mechanic based, and more along the lines of "Who is authorized/must approve" "How do we run accounting" "What is our procurement workflow" "How do you calculate taxes" etc)
    - ghaff 7y ago
      I used to put a fair bit of effort into curating and filing emails, documents, etc. Over the past decade or so, aside from making sure that I put things I wanted to hang onto over the longer term into Archive folders so they didn't get deleted, I mostly stopped filing things and figured I'd just search for them if necessary. Doesn't always work especially if I don't remember quite what I'm looking for. But it's overall a reasonable tradeoff compared to filing a bunch of stuff, most of which I'll never look at again. It is a shift in mindset though.
      - JohnFen 7y ago
        Years ago, I developed a similar habit with email. I like to get emails out of my inbox as soon as I don't need them anymore (so my inbox always only contains the email that still requires my attention). But I don't do any sort of serious categorization/tagging/etc. -- the cost/benefit to doing that far too high. Instead, I have a folder for each entity that I exchange emails with, and move the emails into the appropriate folder when I'm done with them, with no further categorization. "one-off" emails (marketing, registration, etc.) just get deleted.

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.
- NikolaNovak 7y ago
  My mind thinks hierarchically in everything I do so I understand that Google's "Search, don't sort" is difficult to adopt to. (Note, FWIW, though I think we're on the same page - the "business processes" I'm talking about in relation to ERP are less interface/program-mechanic based, and more along the lines of "Who is authorized/must approve" "How do we run accounting" "What is our procurement workflow" "How do you calculate taxes" etc)
  - ghaff 7y ago
    I used to put a fair bit of effort into curating and filing emails, documents, etc. Over the past decade or so, aside from making sure that I put things I wanted to hang onto over the longer term into Archive folders so they didn't get deleted, I mostly stopped filing things and figured I'd just search for them if necessary. Doesn't always work especially if I don't remember quite what I'm looking for. But it's overall a reasonable tradeoff compared to filing a bunch of stuff, most of which I'll never look at again. It is a shift in mindset though.
    - JohnFen 7y ago
      Years ago, I developed a similar habit with email. I like to get emails out of my inbox as soon as I don't need them anymore (so my inbox always only contains the email that still requires my attention). But I don't do any sort of serious categorization/tagging/etc. -- the cost/benefit to doing that far too high. Instead, I have a folder for each entity that I exchange emails with, and move the emails into the appropriate folder when I'm done with them, with no further categorization. "one-off" emails (marketing, registration, etc.) just get deleted.