– “We need a report which groups our sales by product components.”
– “And we need it broken down by cost centers.”
– “And it must show comparison with last month, quarter and year, and with budget and forecast, with indexes and trends. In linear regression.”
– “And it must let you choose if it is by posting date or by document date. Or by shipment date. Maybe some other date as well.”
– “And it must exclude returns, and include only those re-shipments that were linked to original returns in the shown period.”
And it must be a disaster if you agree to half of these.
Continue reading 3rd rule of agile ERP: focus on value
In my previous post I’ve (what, again?) shared some statistics about success and failure rates of software projects in general and ERP projects specifically. It seems that ERP projects fare somewhat worse than generic software projects, which I stated might have a lot to do with how requirements are handled.
Agile is an unpopular word in ERP world. We, the ERP people, love the glory and the thunder of The Waterfall. It has worked for us since forever, after all. Yes, we’ve all seen it fail every so often, but we’ve learned to learn from failure, and we know there is no better approach. Don’t we?
Frankly, I am not completely sure we do.
Continue reading 5 steps to implement ERP the Agile way
Agile has been gaining momentum among software development methodologies for past decade or so. Various researches and surveys consistently show that software developed under an agile approach is generally better than the software developed under waterfall approaches.
At the core of any agile approach is an assumption that whatever the requirements might be at the beginning of a project, they won’t be the same at the end of the project. The longer the project, the more truth there is in this assumption. To mitigate this situation, agile methodologies start with smaller sets of requirements, they start small and deliver functionality incrementally in a series of releases. No single release covers all requirements, but every release delivers more than the previous one.
With ERP implementations, we generally don’t subscribe to this idea. And at that, we might be wrong.
Continue reading Is agile ERP implementation possible?
The degree of fit is an important indicator of your project’s alignment with the standard functionality.
After you determine the degree of fit, and understand what it means for the project, do you just passively accept the findings, or do you do something to make them more favorable?
Continue reading The value of Degree of Fit: understanding risks
I’d like to have a BMW X6. A fantastic car. Only, I’d like it to be convertible, because I love the feel of wind in my hair while driving into summer sunset. I could use a glass roof as well, it makes the interior feel much more spacious. And of course, it can’t have that automatic transmission—I don’t care if it’s not a hybrid car, it simply must have the continuously variable transmission, no matter the cost.
I’ll never have a car like this.
Continue reading Sure Step in action: Degree of Fit