Change

Service Providers (or colloquially partners ) often refrain from undertaking organization or process changes during implementation projects of Microsoft Dynamics solutions. And it comes as no surprise: there are many risks related to it, and customizations are taken as a more traditional approach.

Today I’ve completed delivering the Microsoft Dynamics Sure Step course in Belgrade, Serbia, and I totally enjoyed it. The discussions were great, there was a lot of experience accumulated in that room, and all of the thirteen people attending the training were participating and contributing knowledge.

How do you eat an elephant? One bite at a time. Swallowing it all at once might be tempting as it has all the potential you need to get into the next edition of Guinness World Records . Likewise, trying it with an ERP implementation has all the potential you need to get into to the next edition of Chaos Report .

A few days back, while prototyping a new solution for a customer, one of the key users said: “But in our old software it didn’t work like that.” I was about to try to explain why the change, but then the user’s boss said: – We aren’t implementing a new solution so that everything can stay the way it was.

Four months ago I attended a conference, where I had a chance to listen to Miha Kralj, an architect at Microsoft, talk about architectures. It was one of the best presentations I ever attended, and ever since I had this topic in queue, but never really had chance to write about it.

They say the only constant is change. I’d say that the only other constant is error. We humans tend to err. Give a repeatable task to a human, and they’ll mess it up every once in a while. Some call it the human factor . One of the many repeatable tasks in Microsoft Dynamics NAV is setting up items.