Regarding the second question, it is not comparable at all. ERPs are still "standard" software, despite what the article implies. The difficulty is not so much

Regarding the second question, it is not comparable at all. ERPs are still "standard" software, despite what the article implies. The difficulty is not so much on the software side, but on getting the software actually agree with the business processes and often the fault is less the software, more a convoluted business process which is simply not truly automatable. Then you run against the whole organizational inertia while implementing. I can only speak from a bit of SAP experience: So usually, implementing an ERP, at least SAP, first means "customizing" it, that means adapting the thousands of configuration parameters to the organization. This is no programming task, in fact you "just" operate a GUI. The difficulty is more in finding the proper the option. True development tasks are often very restricted in scope - most often it is just the development of a new report or custom data export (one of the annoying things of SAP ECC always was, that it really really really loves to keep its data to itself. While theoretically everything is open - you can even browse the underlying the database directly from the UI, with appropriate rights, and can also quite comfortable run even DDL statements against it - often you are back to ABAP very soon for any kind of interfacing tasks simply because SAP likes to live in its own world with its own standards for data import/export (Idocs for example or its proprietary RFC interface). Things might have gotten better recently with e.g. the OData support, but I haven't yet worked with a system which had that.