* 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 :)

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.

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.

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.

Will they be paid more for the increase in productivity?

I then began to notice this pattern in other people. If you give them efficient software they wont be able to bullshit their way out of any argument. Productivity is the enemy. Everything possible must be done to prevent the people above from figuring out what is really going on.

One very simple example I ran into recently. A new and improved app was made but it had exactly the same flaws as the previous one. An amount of time is assigned to tasks but if you add up the tasks for a day they greatly exceed the real world number of minutes worked. Then when complaints come in they simply assign extra minutes to the task pushing the total amount of work further over 8 hours. The number of characters for feedback was also reduced. When I jokingly asked about it (knowing how their game works) they pretended it was to hard to divide the work over the day. You cant just say a 70 min task must be done in 50! All hell would break loose! It is then left up to the assignee to figure out how to cut the corners. The managers carefully monitor the feedback, if anyone finds out corners are cut the employee is called in to explain for it. Eventually the smart ones figure out how to cut corners without anyone noticing it.

The entire show depends on the clients inability to add up all the minutes.

[1] - https://www.w3.org/PICS/services-960303.html

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.

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)

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.

No matter how much buy-in you get, people can be unreasonable about making any accommodation for change.

(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)

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.

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.

It's at least 50% sales.

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 )

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.

I would love to see the spreadsheet reinvented to be a) collaboration-oriented, and b) a good on-ramp to ever-growing programming skills. So that when Bob in the next department over makes that crucial internal spreadsheet, you can safely and usefully interact with it from your crucial internal spreadsheet. Basically, to make every spreadsheet a potential microservice.

I've spent some years failing to figure out how to make that work. So if anybody manages, please let me know.

I always envisioned something that functioned like a Jupyter notebook, and pulled some pages from the MatLab debugger tool ...kind of like how Light Table implemented them, but don't get too caught up in that analogy. That way, you could create and define tables that are stand alone objects, and run [code] operations on data in those objects to create new tables. Everything that is processed from the tables is it's own [new object] entity, and can be [output or not] viewed or hidden. It would move away from the idea of having few tabs of large continuous spreadsheets in favor of having many small tables [matrices] that would have identifiers [variable names]. And if the user really wanted, they could drag around tables on a spreadsheet like grid, but the data in those tables would not be editable in that view. Oh, and graphs are their own entity too. Users can use a GUI editor to make graphs, but the graph properties will be user accessible in some sort of markup language for the edge case where the user needs to make a ton of graphs, and then needs to make some styling change to every graph. Not something I've ever experienced though... \s

This will:

1. Reduce the need for Excel's reference gymnastics that are performed when you move or insert rows/columns in to referenced data.

2. reduce the headache that is excel formulas. Since each object will be a formula instead of every cell. Also, the formulas don't have to be a single line, so it will be more readable.

The trick is finding a good language to use - Julia maybe? and designing a good GUI for helping non programmers do useful things like accessing and referencing data from objects in an intuitive way. This could be where the traditional spreadsheet view could come in handy. I like how you mentioned that it needs to serve as a good on ramp for ever growing programming skills, because it needs to be intuitive enough that non programmers can understand the basics and accomplish something useful, but powerful and hackable enough that the mental models can transfer.

You're very right that choosing the right language is important. As much as I love the languages I know, most of them are incredibly fiddly. E.g., things like dealing with "if a=b" are fine for those of us steeped in the mysteries, but a nightmare for more casual users. I'll have to check Julia out. Thanks for mentioning it!

E.g., in an OO language, I can be very clear about what a MailingAddress is. I can say what makes it well-formed. I can give rules about how it can be changed, and what happens when it does change.

But in a spreadsheet, that concept is mostly implicit. A human can look at it and say, "Oh, the mailing address is columns C-G, starting at row 2 and down to just before the first blank line." Until somebody edits the spreadsheet and inserts a phone number column, anyhow.

That means a Google Sheet can't really serve as a reliable microservice that knows about all the customer addresses, letting one's colleague's sheets read and update things. Sheet authors have all the necessary domain knowledge, but not enough of the technical knowledge, so at some point they have to bring in a professional programmer to re-express the domain knowledge in a language inaccessible to the people who formerly had control over their data and business processes.

No VBA, no keyboard shortcuts, (no cross-workbook references).

Imho two people working inside the same worksheet at the same time was never an Excel's missing feature.

FWIW Google Sheets does have the ability to write macros in JavaScript. They even have an npm tool [0] that will let you edit offline via your preferred IDE and then push to your sheet.

[0] https://developers.google.com/apps-script/guides/clasp

[1]https://developers.google.com/apps-script

I got an F.

Splunk is a good example of this. I've worked at several public and private muti-billion dollar orgs, and they all rant and rave about how good Splunk is over whatever else they were using.

So, build more splunks. Maybe something that aggregates monitoring multiple servers. A plug and play Status Dashboard for a company's internal apps. Like this: https://www.google.com/appsstatus#hl=en&v=status

Which potential security threat do you want to eliminate to reduce the splunk bill?

I worked on many CRUD apps that had say 4 different groups of users. We made a library / system for determining what "level" a user is, based on what Active Directory roles the user is assigned. In the application, you can show or hide components based on this level. Making some sort of middle-ware that abstracts things for developers, so they don't have to think about things like AD, is a huge area of opportunity.

So what proxy method would you use to determine that Fortune 2000 companies are spending twice as much on Splunk as they do on New Relic (for instance)?

But similarly, I’ve found it convenient for all my other 2FA needs from GitHub to RuneScape. So even then, it has value to consumers.

So for example, if you would pen an email/slack talking about a slide deck from a recent meeting, in the widget the product would have already found the deck ready for you to drag and drop it into the message.

It worked freakishly good, and saved a whole bunch of time trying to find a file in the mess that everyones Google Drive becomes.

The problem they were having was no enterprise wanted to hand over an entire copy of their data for them to index.

Using AWS for example all it takes is a misconfigured bucket to expose massive amounts of customer data.

Like your enterprises, no hospital (or equiv) would consider exfiltrating their data.

So our gear was physically deployed and operated on each hospital's own system. Our marketing and sales goons called this our "federated data model", which had no tangible connection to reality.

I likened the experience to building model ships in a bottle, while wearing mittens, while someone is punching you in the face. To mitigate, we created what would now be called CI/CD pipelines. We managed 100s of deployments with near zero downtime and effortless rollbacks. I'm rueful just thinking about it.

This strategy didn't survive the 2008 economic crash.

The challenge is the same as the main topic of this thread- change management. You have to force employees to manage their documents exclusively within this system rather than dumping everything into shared drives and using Outlook attachments for everything.

[1] One example: https://www.alfresco.com/ecm-software/document-management

https://cloud.google.com/products/search/

That sounds like a reasonable response. At least, I know that would be a showstopper for me, personally.

The RPC consultants, often titled AI / ML consultants, make money hand over fist traveling from site to site and implementing some automatic procedures.

Same with chat bots. The past 2-3 years there's been an explosion in demand for chat bots, and these often take entire teams to implement and train. Again, lots of bespoke products.

Who gets these gigs largely depends on networking and sales. The big companies (Accenture, etc.) are rolling in this, since they also have a good picture of company software from previous projects.

The accounting industry is also desperate to get in on the ML revolution. I've lost count on how many times I've been contacted by recruiters in that space, who want magic ML pixie dust.

The market is there, but it can be difficult to break into as an outsider, or smaller player - if you're planning in building some one-size fits all product. Best plan, IMO, would be to focus on some niche part of the process, and become the best at just that - and then pitch to the big companies that deal with actual F500 clients.

There are of course exceptions, but a 5 man startup vs Accenture offering the same base product, Accenture is gonna walk away with the gig 99 out of 100 times.

(But with that said, a lot of the startups that focus on these spaces, seem to be ex-consultants from said big consulting firms. Logical enough, as they have both seen the problems first hand, and built networks within the industry.)

https://en.wikipedia.org/wiki/Robotic_process_automation

I noticed that since I worked at the RPA team of my current employer. :-)

This is basically asking for a market gap in a potentially very profitable market. That's silly, everybody wants that.

A lot of ERP systems move away from well-trodden programming tools to their own custom stuff. I know of ERP systems have their own source control version control systems. Why? They're often awful to use. The programmers that use them are often business-focused haven't really used stuff outside that ecosystem. So they don't know how bad it is.

Most ERP implementations i've come across make little use of automated testing as well.

I did some work for a place where, they embedded groovy as their 'write custom rules stuff from the UI' language - that was at least easier to reason about, and to debug/test offline (not automated, but somewhat easier than a DSL that only runs inside the system).

There is always this exception that makes a SaaS ERP not fit for a company.

Hoping to get a white paper or at least a one-two pager in the next few weeks.

Shameless plug, follow here for updates if this sort of stuff interests you: https://hipspec.com/

Just curious if the OP wants this so he can build a product FROM this data, or if he just wants this data as a product, alone.

Why would a Fortune 500 give up such information, which is pretty much how they make money.

Also, if they did map out any tasks that could be automated, they would automate them themselves.

Good idea, but not a product.