by Vjekoslav Babic on December 15, 2010
I’m growing increasingly impatient as the progress bar on my File Transfer Manager is approaching 100%. Behind the cryptical download title—Dynamics.NAV60R2.HR.1097366.DVD.zip—hides the much awaited Microsoft Dynamics 2009 R2 HR (Croatian) release of Microsoft Dynamics NAV.
Yes, Microsoft Dynamics NAV 2009 has officially shipped, and you can download your copy at Microsoft Dynamics NAV 2009 R2 download page. You can also access the NAV 2009 R2 Launch Portal.
This is the first time ever, that any NAV product has shipped simultaneously in 43 countries in the world. For many countries, mine included, this is also the first release of NAV 2009.
[click to continue reading…]
by Vjekoslav Babic on September 14, 2010
Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time. And so on and so forth.
As a matter of fact, if you asked me to pick one single most important phase in a Sure Step project, then it’s the design. No second thoughts here, whatsoever.
Here I list the ten most important reasons that I believe make design absolutely indispensable.
[click to continue reading…]
by Vjekoslav Babic on September 6, 2010
So I would guess that was it. I’m just returning to Kristiansand, my Norwegian base, after delivering the “Microsoft Dynamics NAV 2009 Development Best Practices” course to a partner, my first custom-developed training ever. My impression is—mission accomplished.
I was not sure at first how this would turn out. Teaching NAV best practices to people some of whom have more experience than I’ll have any time soon, isn’t an easy thing. The challenge for me was—how to deliver something new, really valuable to those people, something they could go home with saying “wow, if only I knew this earlier”.
[click to continue reading…]
by Vjekoslav Babic on September 4, 2010
“Best practices” is one of those beloved and hated concepts. There are people who just embrace “best” practices for the sake of their bestness. And there are people who just shun them for the very same reason—those know-it-alls who have opinion on everything and know it better before even learning about it. What’s-best-for-you-is-not-best-for-me kind of people. Neither of approaches is actually, well, best.
For a best practice to be the best for you, you need to understand it, and if you find any pitfalls, improve it.
In two days I’m delivering the NAV Development Best Practices training for a service provider in Norway. They approached me two two months ago and asked if could do something like that. This brought to memory some good posts I made years ago, and here I bring the links. If you want me to share my best practices, this would be my starting point:
- Code of Coding: emphasizes the need for understanding the effects of a change in code, and making others understand your intention
- Code of coding 2: Documenting changes: about how to document different kind of changes in code, and also about the level of effect a specific type of change has in the long run
- Code of coding 3: Die, hard(coding)!: about avoiding embedding output text into code
- Code of coding 4: Die, hard(coding) 2: about avoiding embedding settings into code, with detailed explanation what exactly is wrong with it, and some good guidelines on how to detect less obvious cases of settings hardcoding
- NeverENDing story: about a very bad example I once encountered, and how to avoid situations such as that
- Featuritis Cure: now this one is definitely not a “best practice”, it’s about a situation when a developer pulled a prank on a customer so subtly that I just had to share it with the world. A far better cure for Featuritis (a dangerous and ugly disease indeed) is given by Mark Brummel, in his fantastic post Tip #20 – Save Report Usage. If you aren’t yet following Mark’s blog, now would be a good time to start.
If you are interested in development best practices, check these posts, and if you find them useful, then I’m happy. If you don’t, share your thoughts. Best practices develop over time, improving slowly, and gradually until one day they just become the norm.
by Vjekoslav Babic on March 20, 2009
You can’t avoid customizations. Vanilla ERP is a great first step, and a valuable tool for establishing common language between the customer and the consultant. But in the long run? Probably not. Pristine uncustomized ERP won’t be sufficient, because of the gaps between your way and ERP’s way. Sooner or later, gaps will have to go.
Two most common ways of closing functionality gaps are customizing the software, and changing the processes. You can almost always touch general processes, optimize them, twist them, bend them, make them more efficient or even eliminate them. But when it is about industry specifics that add true value or contribute to company’s competitive edge, customization is the answer.
[click to continue reading…]
