The NAV PG is listening to us.

Well I just got back from Convergence in Copenhagen. I will write up my general impressions over the next few days, as well as blog about some of my experiences there.

One thing I do want to point out that I think is great news is the feedback I got from the NAV Product Group, and form others that are taking notice of bloggers out there. A number of people I spoke with know of the regular NAV bloggers, and take note of what we are saying.

As a blogger myself, it's always encouraging to hear that what I blog about is being used, and I am sure that most bloggers feel that way. Those adding comments and replies to blogs are helping a lot by showing community support for the topics as well

So keep blogging guys, it looks like someone is listening.

What if Homer Simpson became a Navision consultant?

The Homer

At first look, this sounds like a rather bizarre proposition that Homer would be a Navision consultant, yet in reality most new consultants that join the world of Dynamics NAV think exactly like Homer. ;)

Take a look at the episode Oh Brother Where Art Thou? Homer finds that as a child he was separated from his brother. His brother as it turns out is very wealthy, and "owns" a large automobile manufacturer; Powell Motors.

Define the base standard.

The most common trait that most new consultants have when they first work with just about any product is to make a comment something like "But XXX should be standard, YYY product has that feature". This is not just a Navision trait.

So in reality what should be standard, and what should be left out. This balance is a very complex line and very hard to determine. Let's say you add every possible feature as standard, this implies that the client wanting simple accounting must carry the dead weight of all the functionality they don't need. On the other hand if the functionality is not there then the market for the product becomes limited.

Bring on the Add-Ons.

So in its wisdom many years ago, PC&C decided that Navigator (now Dynamics NAV) would have a core suite of functionality, and that the entire product development environment would be open for partners to develop Add-Ons or custom functionality as required for their clients. This allowed the core Navigator product to be extremely simple, fast and most importantly; reliable.

For about 20 years now, Add-Ons have been the way to get a light product that is customizable to deliver what the customer needs. If we didn't have this ability to modify the core code like we do, we would need to have a base product that contained every legal and business requirement of every country in company that we wanted to sell to. What we would have then is The Homer, a huge ugly product that is; impossible for anyone to use because of its complexity; slow because of all the dead weight it is carrying; unreliable because of all the interactions between mismatched code; and expensive, because every client would be paying for every "feature" even if they didn't need it.

Some advice:

• Advice to new consultants entering the NAV arena;
• Advice to those buying NAV, and asking for every possible feature;

buy the DVD and watch Oh Brother Where Art Thou?

Customer it will save you a lot of money that you will otherwise spend six months down the track when you ask the partner to remove all those mods that you really didn't need. Consultants it will make your life easier, and maybe help you understand The Beauty Of Simplicity

PS I think that watching this episode of the Simpson's should be a mandatory part of Navision consultant training. Maybe Microsoft could buy the rights to the episode and put it on every Dynamics NAV install CD J

The most powerful tool that a Dynamics NAV consultant can use.

So you are planning to become a Navision consultant. You are going to show people how to use Navision, how to run their business, and more importantly how to make their business run better.

Of course you already know that NAV application from start to end. You can post any Sales Order, and know exactly how it will affect the G/L. You know exactly which tables will be hit and what the entries will be. You understand Business Process Re-engineering. You are able to perform an ROI on any request that a client gives you. You have studied the clients business model, sought out its weaknesses and strengths, found where those strengths best work with which Navision functionality, and how to best utilize Navision to circumvent the weaknesses. You will be able to guide the client not how to mould Navision to fit their business, but how to best tune their business process, and tune Navision to an ideal balance.

But still we have not gotten to that most powerful tool that you have in your Navision Tool box. That tool is of course.

The word NO! Ne! Nein! Non! Nej! Nyet! Nie! Nem!

There is nothing else that will make the implementation more success full, nor give you a happier client than the proper use of the word no.

Generally one of the golden rules of sales is "The Customer Is Always Right". Well in the ERP world, that just isn't true. Of course as Dynamics NAV Consultant, you arrive on the scene after the sales process. So you have some work to do. When you get assigned to a Navision project, the first thing you must do, is go through all the paperwork, and review all the promises that the sales person made, and then get out a big NO from your tool box, and start using it.

All too often, one or two yes's sneak through the early project phases, and yes's are like rabbits, they bread like crazy. At first it all sounds great and happy, but a month or two down the line when you are trying to work around all these promises, you will realize that it would have been better to have been up front at the beginning. You will read some humorous statements like "We want to use pop-up to speed up data entry and make it more accurate". As a consultant you know that pop-ups make data entry much slower, and reduce accuracy, so say NO now, don't wait till the customer is live six months and then finds all the data errors.

Clients respect honesty.

This seems to have been lost somewhere, but if a customer makes a suggestion, that is just wrong, then … Just … Say … NO … ! it won't hurt you. When you tell the client why their suggestion is wrong they may react with disbelief, but give it time and that disbelief will grow to respect. It is very important to understand that your client most likely does not know Navision very well. That is why they engaged your services. They need you to tell them the best way to use the system. And sometimes that means just saying "No that just is not the right way to do this". Suggest to them the proper way.

I don't know.

Also don't be scared to say "I don't know", just make sure to follow-up with a "I will discuss it with the team back at the office and get back to you on ..." Just be sure that there is a team back at the office, and at your weekly team meeting don't forget to throw the issue around for ideas.

Anyway I just wanted to have this little rant, because I believe that if you are not capable of saying "NO" sometimes, then you are absolutely not capable of working with Navision, and you should leave and go to a different industry.

Dynamics NAV 50,000 range objects.

All NAV clients know that to add additional functionality to NAV they must purchase run time license access to access the development made by their partner.

A very few lucky clients will be told this by their partner during the sales process BEFORE they sign a contract. The majority will learn this before Go-Live during the gap-fit analysis when the development estimates come in. Then a very unlucky few will learn after they have committed to an enhancement and it's too late to do anything except pay.

The cost of these objects (when put into perspective) is quite low, so I can never fathom why partners don't make this very clear before signing, instead of the belated excuse of "Yeah well its right there in the price list, surely you did your due diligence and read the price list".

In my opinion though if your partner caught you like that, then you have a lousy partner.

But that is not what this blog is about. This is about a common practice I see from partners that I find totally unacceptable. And that is using the 50,000 object range for development.

The range of objects from 50,000 through 50,099 (50,009 for tables) was intended to be used by Clients that purchased the NAV development tools. Commonly many clients are advised to purchase the basic designers

• Report designer (7,110)
• Dataport designer (included in 7,110)
• Form designer (7,120)
• Table designer (7,130)
• XMLport designer (7,140)

Obviously to use these they need access to objects, and thus the inclusion of basic objects for them to create their own forms and reports, and later some tables. But very often I see that the partner has already started development at the 50,000 range, and thus 6 months down the track the client is ready to start development, and is told "Ah well you need to buy tables and forms, because we used the all up during the Implementation process. So since ten tables cost the same as the table designer, from the client's point of view they have to go out and purchase the development tools all over again.

This is shameful.

When you perform development for a client, you should define a range that your company will use, and start there. DON'T start at 50,000, and you will thus completely avoid this issue, and most importantly you will avoid a horrible argument with your client all over a lousy $800. When I quote modifications to a client, I would make it very clear the difference between buying one table for $200 or ten at $80 each. But make it clear, don't just sneak it in as a line item at the bottom of the quote.

Of course there are clients that will never use 1000 reports and 10 tables, so in those cases, sit with them up front, be frank and open with them, and tell them that it's not recommended practice, but if they want you can develop using the 50,000 range. What customers hate is deception, or at least the feeling of being deceived.

Which RSS aggregator do you use to read Dynamics NAV blogs?

Well I know its not an exciting Blog topic, and probably really belongs in the Forums as its not a true Blog as such, but putting it here as well, means that the people using RSS to read Blogs will most likely see this. 

I think I need to change my RSS reader, and I was curious which one people are happiest with for reading Navision type blogs.

• The sort of things that concern me are:
• Clear indication of what was updated.
• Ability to sort by topic or date etc.
• Able to group many differnet feeds in a logical manner.
• Doesnt over load with information

 Thanks.

Why I don’t want my clients to use SANs for Dynamics NAV (Navision)

I am sure I am not the only person that has had to argue with a client as to how hardware needs to be configured in a Dynamics NAV environment. Typically bigger companies with larger internal IT support generally have their way of doing things, and its often very hard to sway them to do things "The Navision Way" As well as new implementations, I often will be asked by a client if they should switch to SANs This Blog really is about and kind of "Virtual Storage" system, and to some extent even partitioning disks.

What is a SAN?

Basically a SAN (Storage Attached Network) is a box (or boxes) full of hard drives that are bundled together into what are called LUNs. These LUNs are accessed by the server through (typically) a fiber channel. The server can then create drives on those LUNs, much like where in a DAS (Direct Attached Storage) environment you may have logical drives created on Partitions of a Physical drive. If you are not familiar with SANs and DAS, then a quick trip to Google might be good at this timeJ. It will also help if you understand a little about Latency, Transfer rate, Seek time and Number of Platters.

From the point of view of this Blog, the key difference between a SAN and DAS is that a SAN can be shared across multiple Servers with ease. A DAS is really only connected to one active server at a time.

Why do users want to use SANs?

SANs generally offer the following advantages over DAS

• Cost is much lower in multi server environments
• Better utilization of total physical volume space
• More effective disaster recovery process
• Easier maintenance
• Simpler backup strategies in complex environments.

1 and 2 are generally linked, since the cost reduction is mainly due to better utilization of the actual space on a disk drive. Though of course having less boxes and power supplies etc. and even lower air-conditioning requirements makes SANs cheaper.

3, 4 and 5 relate to the fact that you have everything in one box, so you can easily switch things around as required.

The SAN magic

Before we go much further, I must say that SANs really are the greatest thing since sliced bread, and every big organization should be using SANs; just not for Navision.

Spindles and heads

So lets get to the issues. In any transaction bases Database environment, pure disk through put and thus posting speed comes down to the number of spindles and the positioning of heads on the platters. If we look at a typical medium to large Navision SQL setup (say 100+ gig db and 100+ users) , we could have a scenario where 16 drives are configures as 8 RAID 1 pairs and there are 8 ndb files on those drives, 1 per RAID array, or we might have one big NDB file and the 16 drives are configured as a large RAID 10 array.

There are advantages and disadvantages of both, but that is not relevant to this discussion. The key issue here is that the database is accessing 8 spindles. This means that we are writing 8 streams of data in parallel, so the transfer rate (and thus commit speed) to this array is about 8 times faster than if we had one large RAID 1 drive. Now lets say the Database is 100Gig, and we have say 16 x 73 gig drives, a total of 1,168 Gig of which we use less than 10%. We do this, because half of this is used for redundancy and really we are using about 20% of 500gig of mirrored space. We do this for performance. And I think most people are aware of this. OK, so if we have all the spindles we need, what can we do with that free space. Well not much; we might say that the Navision server is dedicated to SQL on Navision and we don't want any other applications running on that server. But that is not the real issue. What is the issue, is that we want the 8 spindles all being used by Navision. If we decided to put something else on the drives, even a small application, then the data through put is no longer dedicated to Navision, so the system will slow down.

In general this is pretty easy to follow, and has applied since the early days of Navision and equally applies to SQL. What is more complex a concept to grasp is that of the LOG file. So lets look at the log file.

The first thing we can notice about a LOG file, as compared to the database, is that the drives are very much quieter. Now typically in our scenario, we might have one or two log files either on a RAID 1 or RAID 10 array with 2 or 4 drives. Again lets no go into the difference between one or two log files, for now, but the principle in general. So lets say we have 2 log files on one RAID 1 array:

The log file works very different to the Database. A log file is written and read from sequentially, so the number of spindles really does not have a huge impact on performance. What really matters is keeping activity on the drive as low as possible so as to reduce the effects of latency and seek time. In fact if we can keep the heads writing a single linear transaction, then write time will be a lot faster. The reason is that if the heads move then we have issues with seek and latency to get back where we were. So the key to the log file is to have that spindle and head working ONLY on Navision's log file. Even the smallest file on the drive being accessed will degrade performance significantly.

In an ideal scenario. The head sits virtually still, and the drive rotates. Assuming Latency is matched to rotation speed, the drive will simply continue to write to the track, one it completes a full write, the head moves only a miniscule amount to the next track and continues on.

Now lets look at a scenario where we share a small part of the drive with another program. We have performance issues to contend with now.

Each time we access the other program, the head has to move, AND we have to wait for the platter to rotate to the correct position. Then we have to do this again to go back to the log file. In this scenario, you can increase your seek time by 20 times which will absolutely kill SQL performance.

The simple version

Basically what I am trying to indicate here is that if you want Navision to really fly, (and this applies to Native as well as SQL) then you MUST have dedicated multiple spindles for the database, and a dedicated head for the transaction log that does nothing but the transaction log.

Why SANs are bad

But of course, by now everyone is asking what this has to do with Sans. So lets get to that. OK, the point is that there is nothing wrong with a SAN per se. The issue is in configuring the SAN, and in that there are three issues.

1. Do you really know how to configure the SAN
2. Is it even possible to configure it correctly
3. Will you be tempted to use up all that free space.

    

I have done a lot of Navision implementations, and I have recovered a lot of disasters for users. I must say that in my many years, I have NEVER once seen a SAN that was correctly configured. Generally due to one of the three reasons above. 1 and 2 really fit in the same box, and often the IT department truly believes that the SAN is configured to have dedicated multiple spindles for the Database, and dedicated heads for the LOG file, where as in reality the LUNs are actually spread over multiple drives without any specific control of what is placed where. So even though they thing that the LUN they are representing as a RAID 10 drive is made up of 16 drives, it may be made up of just something that the SAN represents as 8 drives. And in fact the LOG file may be sitting on the end of one of the drives that has a part of the database on it.

But the killer in most cases is 3/ above. Often its hard to tell the bean counters that of the 1 Terra Byte of disk they bought, that they will only use 100Gig and the rest will just sit idle. So suddenly we find that a month after Navision go live, things have slowed down. With the way SANs work, the Navision specialist will look at the drives, and see 16 drives dedicated to the DB, 4 drives dedicated to the LOG file, a TEMP DB sitting on its own RAID 1, but for some reason 2 DB parts are very slow, and the log file is crawling. The client will blame Navision, and it will take a while before someone discovers that the SAN is being used to Host Exchange and Active directory, since all this is totally invisible to the Navision SQL server.

Summary

Yes SANs can be used in a Navision environment. But if you are going to use a SAN, then be fully aware of all the implications, most importantly you need a SAN dedicated to Navision, because if it is not, then eventually somehow you log file will share a spindle with a 200 user Exchange server and performance will go down, locking will be more prevalent, and the Client will say that it's a Navision error.

So if a client wants to go for a SAN then I just ask for two things.

1. The SAN is dedicated to Navision
2. Its very clear that the user can configure the specific mapping of spindles to LUNs

PS and for those who haven't guessed yet. I am currently working with three separate Navision Clients each that have performance issues, and so far only one of them has acknowledged that the SAN is probably not configured correctly. They are (I hope) reading this blog J

Select * FROM and how to do it better in NAV

Some background

I met with Mark in Barcelona some time back at Tech Ed. We had both just been to a SQL (not NAV related) session, and it opened both our eyes at that moment as to why the Select * in NAV is so bad. I did my first NAV performance tuning job in 1993, (Navision on OS/2 Warp) so I am not new to performance tuning, and since most of my years in NAV have been spent recovering clients form disasters, I generally get to see the worst end of it all. Now-a-days I am seeing a few largish NAV/SQL implementations (500Gig+) and still most of the performance issues are just simple common sense stuff that is easily fixed. But this is not a thread about how WE can make NAV faster, its about how Microsoft's NAV team can make it faster.

The issue.

Everyone knows that Select * is bad, and that it needs to be fixed, but the issue has always been how to actually implement it in NAV and of course it needs to be simple. After some thinking, I feel I have something that may not be a solution, but a good starting point, so hopefully someone in Denmark might read this.

The first issue is; where is Select * a problem? Well one of the big issues is where SQL needs to scan a lot of records in a fat table (one that has a lot of large fields). A typical scenario is the Item Ledger Entry table, which can be from 1.5 to 2k in size. But in many cases, I the developer is really only interested in knowing (say) the Item No, the date and Quantity. So I only really need to tell SQL to get me those three fields, instead it gives me the full 2k, including all the Fields I filtered on (like say Location code) and thus know already. In a database with say 10 million records, SQL will often say that since you are requesting * its faster to do a clustered seek on Entry No and thus it reads everything. When I really only need maybe 20 bytes not 2,000. And of course if SQL did not have to retrieve all that junk that I don't even want, it would probably have used a better execution plan so would not have read 10,000,000 records.

The Solution

So what about a new Variable Type in NAV, basically a Record still, but with a property that lets us select which fields we want SQL to give us. For simplicity lets think of a new Variable Type and call it "SQLRecord"

Well first let's look at the issues that we need to solve:

1. How to define the select statement from C/SIDE.
2. How to assign SQLRecords to Records
3. Passing SQLRecord as a parameter
4. Using SQLRecord
5. What about Native

1/ How to define the select statement from C/SIDE.

This would be the easy part.

Properties would show:

So now we have a variable and we should be able to use it much like a normal Item Ledger Entry Record, except that when we request this from SQL, instead of sending

"SELECT *FROM…", it would create

"SELECT [Item No_], [Posting Date], [Entry Type], Quantity, [Completely Invoiced] FROM …"

2/ How to assign SQLRecords to Records

I see two possibilities assign fields one by one, or TRANSFERFIELDS. My preference would be not to allow transfer fields. I think that field by field assignment is a better solution, such as

ItemLedgEntryWork."Item No." := ItemLedgEntry."Item No.";

ItemLedgEntryWork."Posting Date" := ItemLedgEntry."Posting Date";

I generally think this safer, since the develop clearly can see what they have done. Also it addresses the fields not in the SQLRecord such as Location Code etc, that may have been the filters on the original FINDSET. The other option would be to allow TRANSFERFIELDS, but I see this fraught with problems.

3/ Passing SQLRecord as a parameter

I see that this is one of the bigger issues with SQL Record, since in NAV if you passed this as VAR with all the filters sorting etc. The called function needs to be fully aware of the SQL Fields that are viable in this Variable. If its is passed not as VAR, then what are we passing. The key issue here is that allowing any passing through a function assumes that the developer is fully aware what they are doing. Much as you can pass an Option Variable or field to a function, but really since its actually an integer, there is no real connection at the other end. E.g. you can have a function that requires passing SalesLine.Type, but there is no problem passing SalesLine."Document Type" instead. So the question is if passing a SQLRecord would force type matching, i.e. that the "SQL Fields" Properties are exactly the same for the Called Function and the Caller. Since we must assume a developer knows what they are doing, (and they can just as easily mess up by manually assigning the wrong fields to a normal record and passing that, that it should not be mandatory that the SQL Fields are identical, though obviously it must be from the same Table.

4/ Using SQLRecord

In principle this should be no different to using a normal record variable. INSERT and DELETE should not be possible, but the normal FINDFIRST, FINDSET, Get etc should remain the same.

When you press F5, you would only see the fields that are available in the SQLRecord's "SQL Fields" property, so it will be easy to se what fields are available, and trying to assign a field that is not defined should give a compiler error.

What also this record type will do, is make developers think more about what data they really need, instead of just assuming that they can get everything they want.

The property should also be available in report designer, so that reports that need just a handful of fields from rather fat tables, don't have to get so much data when that data will never be used.

5/ What about Native

In Native there should be no special handling, obviously there will be no performance improvement (since there are no plans to modify native Server), but the code should work without problems.

In Summary

Well it's just an idea, and yes I know that there are many other ways to speed up NAV, but this is just one more of them. And I know that there are a lot more issues to resolve than just those I mentioned above, but I don't see this as insurmountable. Of course I am by no means a SQL expert, so maybe I am overlooking something obvious, and any feedback would be much appreciated.

Lets hope someone in Denmark is reading this blog. (Or maybe I will just forward someone a link).

david

Creating a Blog on Dynamics Users Direct from Word (part 2)

In an earlier Blog of mine http://dynamicsuser.net/blogs/singleton/archive/2007/09/07/creating-a-blog-in-word.aspx I discussed creating a Blog directly in Word. This is a great way to blog, because you can just create a word doc and start typing away. If you have SnagIt, you just drop screen shots into the document, create tables, basically most of what you can do in Word. And when you are finished just hit the publish button.

But looking back, that post was pretty short on detail. So what I am going to do is create this blog in Word, and go through the steps involved to publish it.

Blog Setup

For this exercise, lets assume that there is a user on http://dynamicsuser.net with the

Log in ID FredJones

Blog ID : FredsNavBlog which is seen at the

Location : http://dynamicsuser.net/blogs/MyNavBlog/

Step One Setup:

a/ Create A New Blog Template.

b/ Enter Your Blog details:

c/ Enter the settings:

The next step asks about uploading pictures. We will cover that later. For now create the Account. If you get a message that the Account can not be registered, then either the Blog has not been created, or maybe you have the Blog name wrong. So post here http://dynamicsuser.net/forums/t/1370.aspx : and I will help you out. You of course need to get your user Id and password correct.

Before posting for help, please note the following. Your User Name and Blog ID and Blog Name are probably not the same. For example, my user Name is "David Singleton", but my blog Id is singleton, so the blog post URL for my blog is http://dynamicsuser.net/blogs/singleton/metablog.ashx if you have any problems, post in the thread http://dynamicsuser.net/forums/t/1370.aspx and I will get your correct details, (except password which I can not access).

If all went well then you should see this message:

You should now be able to create a test blog and publish it.

And on the Dynamics User Front Page you will now see this.

Uploading Pictures

If you want to automatically upload pictures you need a site that can host them for you, or you could use your own site for this. To do this go back to Manage Accounts and Change settings for your Profile:

When you publish next time, if there are pictures, then you will need to enter the FTP password for the site.

Well I think that's it. If you have any questions, please ask.

Test Blog From Word 2

Just a test as a part of my next Blog.

With a picture:

If it takes one person 10 days to dig a ditch, how long does it take 10 people to dig the same ditch?

A simple question from primary school math class. If your answer was "one day" then you are wrong, if you said 10 days you are probably also wrong. If you said 5 you are getting warmer.

My first job after University was working on a Gold Mine. I eventually worked up to mine manager, and managed the largest Vat Leaching Gold Retreatment operation in Australia, so moving dirt is something I know a lot about. I am not sure how many people out there have to dig big holes in the ground, but I thought some of my gold mining experience may be useful for others that plan to dig a ditch in the near future.

This is the first of a series of Blogs to help people that plan to dig Ditches.

When one person gets down to dig a ditch, the job is very clear, you take a shovel you get a wheel barrow and you dig. You don't need to tell anyone what you are doing every hour; you don't have to worry about anything except digging the ditch.

But lets say we are in a hurry, and we need our hole dug faster, the only solution is either to dig faster, or get some people to help out. So lets look at the process of digging a hole for a paying customer and see how we can speed it up.

So the project plan:

1. Discuss with the customer the plan of the hole.
2. Decide how you will dig the hole.
3. Mark out the area to dig.
4. Get tools and start digging.
5. Have customer check after about 1/4 of digging that the hole is being dug according to plan.
6. Back to work and Complete the hole.
7. Have customer accept and sign off that hole is correct.
8. Clean up the area around the hole.
9. Put away tools and write up an explanation of any issues found whilst digging the hole.
10. Send invoice to customer.

The Design Process:

Now since its just you, the customer takes you to the spot where they want the hole dug, you both sit down with you mug of coffee, and decide the best way to dig the hole, and draw up a plan:

http://www.dynamicsbook.com/images/HoleDesignPlan.gif

The Implementation process:

Next you look at where the hole is, and what tools you have, and where the dirt needs to be move to, and you work out the details, such as how do you get the dirt up the 2.4m, how far you cart the dirt etc.

http://www.dynamicsbook.com/images/HoleDevelopmentPlan.gif

The Quotation Process:

Now I have dug a lot of ditches, and I am very good at getting a full shovel load each time and can dig very straight, so I know that I can dig about 1.6-1.8 meters per day for a ditch of this depth and width, and I know that the ditch will be square and the sides of the ditch smooth. So it will take about 8.5 – 9 days of digging, which includes wheel barrowing the dirt 50m or so to where I dump it, and it gives me 1-1.5 days to handle the issues with getting the ramp setup, clearing and dirt that falls back in etc. I told the customer, that if there is any water in the ditch, then we have to re-discuss this, because I am basing this on a dry ditch with no drainage issues.

Now because I am a very good ditch digger, and very fast (someone else would probably take 20 days) I have given the customer a quote at my rate for 10 days work. The customer came back and said that the cost is OK, but they really need the Ditch dug much faster, so can I propose options. So now I look at ways to speed this up.

Of course the first thing I can do it to get an assistant to do some of the less complex work. For example I could have someone with limited ditch digging experience Take the dirt away in the wheel barrow. So lets look at that.

Wheel Barrow Assistant:

This person will take the dirt away, so that I can spend more time digging. Since pushing a wheel barrow is much simpler, I can get someone with much less experience (AKA Cheap). But I also now need a second wheel barrow, and more importantly how do we now get the empty wheel barrow down the ramp when we have a full wheel barrow at the bottom of the ramp. So the first issue is that we have now added technical complications and that requires extra Ditch digging planning. So probably we need to take the full wheel barrow out before bringing the empty one down. Also working by myself every time I go up with a full barrow load, I stop on the way back, review the overall progress of the ditch, take a drink of water and clear my head out a bit. So really have I gained anything just by having a wheel barrow assistant.

Furthermore any minor changes I make like this may cut the time from 10 days to 9 days, no where near what the customer wants. What the customer wants is to have ten ditch diggers to dig the ditch in one day.

Use 10 diggers for the job:

So lets see how this would look.

http://www.dynamicsbook.com/images/HoleDevelopmentPlanUsing10Diggers.gif

This is starting to look good. Clearly we can see that the 10 diggers can dig this ditch much faster. The first glance of this plan shows one immediate issue. Where do we find 10 top notch A grade ditch diggers, that are all going to be available to dig this ditch. In fact that is not a big problem, because the Elbonian Off Shore Ditch Digging Company can provide me with as many fully certified Ditch diggers as I need. So let's get down to practicalities and see if we can make this work.

Taking a closer view, I can see one thing missing, and that is wheelbarrows. Each digger has 1.5 meters of space, and that does not leave much room for the wheel barrows and of course we seem to have totally missed out the fact of how we get the wheel barrows out of the ditch full or dirt. Hmm odd, it looked good on paper, why is it not looking so good in the real world.

The net issue is that the Diggers are going to be getting in each other's way, 1.5 meters is not a lot of room to heave a shovel full of dirt, and its too deep to throw dirt 2.4 meters high. So let's look at getting some more wheel barrow assistants to do that work. In that case, I know that about 20% of my time is spent wheel barrowing, so let me get 8 diggers and 2 wheel barrowers, and that should work, in fact since wheel barrowers are cheap, let me get 3 of them to make it even faster.

Next we probably need to work a new way of getting the dirt out of the ditch into the wheel barrows, so we will need to set up some stations with buckets and pulleys to get the dirt out. In fact let's get 4 wheel barrowers, 2 on the barrows, and 2 on the pulley/bucket set ups. Next I see that each digger has a different preference for the tools they use, form Round nose shovels to square spades, picks to breaking bars. So to avoid having all that stuff in the ditch, let's get a Tool getter to get the diggers the tools they need. Since Diggers are the most expensive, it makes sense to optimize their time.

Also I am thinking that instead of them taking breaks for water and food, better will to be have someone to do that also. And after talking with the new manager, it seems that even though these Ditch diggers all have years of experience, and certifications for everything, most of them though they can dig a basic ditch, aren't really able to dig the ditch straight, and the walls tend to cave in a lot, so we will need a surveyor with a theodolite to keep the ditch straight, and we will need 2 people to manage trench boxes and keep the walls from collapsing. Also lets pick the best two from the eight diggers and have them as leaders to coordinate them, to save time from the manager.

Now my job will be to manage and coordinate all this, but to be honest, this is going to run pretty smooth, so I could go out and be looking for more work, and I could get in a manager to look after the job and make sure it's running smoothly. In fact I probably only need to be there at the first kick off meeting, then I can get out and sell more ditches.

Revised plan with 10 Ditch Diggers:

http://www.dynamicsbook.com/images/HoleDevelopmentRevisedPlanUsing10Diggers.gif

Now this looks much better. And it looks like we can have the ditch now dug very fast. So let's revise our implementation plan.

Revised project plan:

1. Discuss with the customer the plan of the hole.
2. Develop project plan with the job manager and the surveyor and customer.
3. Review plan with the trench boxers, and revise as required
4. Have customer sign off on plan.
5. Work out testing and acceptance points so that we manage expectations.
6. Mark out the area to dig.
7. Have project meeting with the whole team.
8. Work out logistics getting to and from the site
9. Setup the pulley/buckets
10. Map out the path to carry dirt so we are not crossing paths.
11. Setup food and drinks stations.
12. Test out communications channels.
13. Organize all the tools required, have spares of each type as required.
14. Have customer check after about 1/4 of digging that the hole is being dug according to plan.
15. Have follow-up management meeting to review discrepancies and determine plan for getting back on track.
16. Back to work and continue digging the Ditch.
17. Have review meetings at each mile stone or target point.
18. Have customer accept and sign off that hole is correct.
19. Clean up the area around the hole.
20. Put away tools
21. Have team meeting and create core issue list from the digging of the ditch.
22. Write up an explanation of any issues found whilst digging the hole.
23. Send invoice to customer.
24. Pay salaries

The next Blog in this series will look at what we learned when we scaled the operation from one Digger to ten, and how much faster we got the ditch dug.

For now, I would like to ask those with experience digging ditches, what issues can you see that our team had in digging the ditch with 10 diggers, and how long do you think it actually took us to dig the ditch.

Directions 2007 (Orlando)

Passport

Many years back, Navision USA used to run a Navision event called Passport. This was a Navision Partner (NSC) only event. Basically it was a networking event, though since most of the people there were competitors, there was not too much practical networking and there were no heavy technical sessions, so it was more of a gathering of like minds than anything else. In any case though, Passport was a great event. After the Microsoft acquisition, passport died, mainly because the event was "free" (i.e. you only paid for travel and accommodation, Navision paid for the event). And eventually we got Convergence, which was the old Great Plains version of Passport.

Directions

Definitely this left a gap for partners that were concentrating on NAV. So a few ISVs got together and thought it would be a great idea to bring back the idea of Passport, and concentrate on just NAV, and in the process, get more exposure to ISV solutions, and get some more technical tracks that are of interest to NAV Partners. So came about Directions (www.cronususa.com). I have never been to Directions. The inaugural event did not get a lot of publicity outside the ISV network, and by the time I found out I was already committed to other work on those dates. Last year I was very busy with a multitude of MVP events, and cold not squeeze it in. But this year at Convergence Mary Lanham, one of the founders of Directions has convinced me that I really should be there.

Microsoft Sponsoring Directions

Last year Microsoft were "at" directions, but this year it really does look like a Microsoft event, not just them being the major sponsor, but more importantly they are sending key personnel to the event. Most significantly Kirill Tatarinov will be there giving the Key Note, so that sort of says that Microsoft are taking this event seriously. Maybe even to the point of replacing Convergence in some respects. There is even a day devoted to NAV 6.0. I am sure there is nothing too new there, but it will be great to have it all in one session, instead of bits and pieces all over the place.

The Future of Dynamics NAV events

Convergence EMEA this year was clearly what Microsoft said it was supposed to be, a customer sales event. So it would appear that all the real content will be moving to Directions, and I think this is a good move. I personally don't plan to attend Convergence EMEA ever again, but if Directions can deliver what it promises that wont matter.

Anyway, let's see how it goes, I am expecting a lot from this event, and will keep everyone updated. Though Eric (aka waldo) is there, so I am guessing that by the time you read my Blog, he will already have posted everything you need to know. (Keep up the great work Eric).

Dynamics NAV 5.0 comes of age

Ok, the product we thought of as 5.0 then 5.1 and now 6.0 (or just "The Three Tier Client") has been delayed. Ranting and raving won't change that, I don't want to comment in this blog about my opinions of the product delay itself, but I will say "Microsoft you really should have done a better job of communicating all this to your customers". So let's get back to business, and concentrate on 5.0.

Dynamics NAV 5.0 – the red headed step child.

Unfortunately 5.0 really has gotten this title. It was born out of some rather hastily released statements about the next version of NAV, and unfortunately has been very much misunderstood by the market in general. I have worked with every version of Navision (except 2.65) from 3.04 (DOS) through 5.00. I have upgraded to just about every version in that range. Often the next version of Navision is great, often its bad. But its rare that Navision get it right first go. In this case though, they really got it right. 5.0 is a very solid product. None of this nonsense of trying to release lots of new "features" (Features generally can be read to mean "new bugs" or "new things to sell") but this time lots of serious fixes. Inventory costing now does what everyone wanted it to do. At long last those ridiculous phase task steps are gone from Jobs. I can now hit a button and get my data to Excel just like every $99.99 piece of software on the planet can do. 5.0 finally got it right.

What about Service Packs?

I mentioned that often they don't get it right the first time. When you look at solid version of Navision, (You can read more about NAV versions on the Dynamics Book Wiki http://wiki.dynamicsbook.com/index.php?title=NAV_version_history) you always see a 0.01 or B or SP attached to the name. for example 1.1, 2.01, 3.10, 3.70B, 4.00SP3 these are the solid versions. What this meant, was that Service Pack 1 was always the fix for all the newly introduced bugs. But this time the version is solid, so the service packs will be something different. This time service packs can actually deliver something useful. I think that if NAV can keep this up, they will have a much happier client base, since it will mean you can upgrade to the next version, knowing that its solid and reliable, and then wait for the service packs for all the nice stuff to come. So assuming that Service Packs are what we get between now and 6.0, what should those service packs cover.

Three tier, Web Services and Reporting Services.

The major feature touted to the public of 6.0 is the three tier client. But what is this. Well in reality its all about a new graphical interface, which in reality is nice and pretty, but not really the thing we need to run out business. We have seen so many far more important features such as Web Services and Reporting Services. Although we can sort of do Web Services in 5.00 using NAS, its far from being an ideal solution. So if I could add to my wish list just one feature I would like to see in 5.00 SP1 it would be Web Services. In fact everyone I have spoken to about what they have seen so far from 6.0, the one feature that stands out is Web Services, NOT the new graphical client. As a #2 I would say Reporting Services. Not because it's really needed now, but it will be great for companies to start now that huge transition of reporting as soon as possible.

Web services as a part of a service pack for 5.0 would give users the ability to start simple systems integrations using Share Point. This would make 5.0 the version to upgrade to. As a company would then be able to build its integration and future development paths now, knowing that they are working on a system that is moving into the future.

Please Microsoft, if you can give us just one thing in 5.0, make it Web Services.

5.0 vs. 6.0 data structure (tables).

The next step on the way to the next version is the upgrade path. The FAQ issued by Microsoft tends to cryptically reveal that the 6.0 table structure will not be the same as 5.0, but the FAQ did not clearly state whether a service pack for 5.0 will change to the new table structure, or if 6.0 will have new tables that will require data conversion. Either way its not issue, but please don't keep this a secret. Just tell us YES 6.0 will have new tables and the upgrade will require a conversion process. Then clients can work now to build their upgrade strategy.

Now vs. the future.

Version 5.0 is a good solid product, and offers clients many reasons to upgrade. I am very happy with results so far of running older objects on 5.0 executables, so if you can't do a full upgrade, at least get on the latest 5.0 executables. (http://wiki.dynamicsbook.com/index.php?title=NAV_technical_upgrade ) But for many customers the new Inventory valuation tracking and reporting is worth the upgrade. Of course if you have been thinking about using jobs for a while, and putting it off, then look at how jobs work now, and you may find it time to start using them.

Either way, things seem to have settled now, and now does seem the time to plan an upgrade to 5.0.

Creating a Blog in Word

This is just a test, but could be very usefull.

If you have Office 2007, then you can create a Blog entry directly in Word. You save it like a normal .DOCx file, and when finished, just hit the publish button.

So you can do all Word type stuff

All this done in word and I didn't even open the DUG Blog Page

Learn Dynamics NAV (Navision) in India

Through the years I have watched Navision grow through different phases in different countries at different times. The pattern is always quite similar, and at one stage it reaches a point where growth in the country out paces the time needed to properly learn Navision implementation skills, this means Analysis, Consulting, Development etc. Generally its not a lack of good people with great business and computer skills, its not normally even a problem getting up to speed with Navision development, in the end it comes down to evangelizing "The Navision Way" to those people to make sure they work the way Navision works.

 
In the Dynamics Book Wiki http://wiki.dynamicsbook.com there is a great deal of information about the correct way to do things in Navision, also there is this site http://dynamicsuser.net which has for the last 12 years been the number one source for Navision information.

 
But really there is nothign that replaces real world experience in a real world environment. So throughout the years, a large percentage of the work I have done has been training new Navision developers and Consultants on the ways to get the best out of Navision. Well now I see that the region that is growing the most is APAC, and that drive is all coming from India. So I would like to do some high end Navision training in India. First of all though I need to know where it is most in demand, so if you are interested in Navision in India, please answer this Poll to help me get started. : http://dynamicsuser.net/forums/p/19625/89935.aspx 

 
The thing about Development in Navision is that Navision programming is very easy. There are only a few commands, and they are easy to learn. The issue comes as to where to put the code, and how to do it the simplest way that gives the best result to the customer, is designed for performance, and is future proof, in that its easy to upgrade (amongst other things). I believe that it is not about passing exams and following text books, more its about being skilled enough to pass an exam, and then knowing how to use that skill to generate a genuine ROI on every project you do for a client.

Boeing 787 Dreamliner part 2.

OK, so back to computers. Well often we do hear comparisons between the evolution of computers, aircraft and cars. Mostly they are somewhat arbitrary, but still.

This year we saw the release of Vista and Office 2007. Later we will see never versions of Great Plains 10 and Navision 5.1. In terms of revolution, 5.1 is revolutionary, it is as big a jump as the jump from Dos to Windows. 

But when most people think of Office 2007 and Vista, its much like the 787, just another upgrade. Both Vista and Office 2007 look very much different than their predecessors, but really that is barely scratching the surface of what these products deliver. In fact they introduce a whole new way of delivering for Microsoft.

The biggest change in Office 2007 in my opinion, is the "one version of the truth" concept. The idea that data is secure not only form outsiders, but even form those inside. Its now possible to email a spread sheet to 100 people, then go to a meeting and have just one version of the data in the presentation. In our ERP world, this ability of people to simply take data and manipulate it in excel was a tough nut to crack.

What has happened, is that instead of having isolated desktop applications on isolated desktops, we now have a truly integrated office environment. And those companies that think "we will wait for the next version" need to take a close look at 2007 and what it offers. Personally I think MS are doing too much hype in the "user experience" areas, and not showing off enough of what is going on in the back ground.
 

And then we have Navision. This next version (which we hope will be released some time this year) will change the way we think about ERP in the Navision world. No longer will we be able to think of ourselves as C/SIDE developers. More and more, C/SIDE will be come less and less important. We will be soon able to hand off parts of Work Flow to the user though MOSS (Microsoft Office Share Point Server). And users will control their own User Interface.

 
Looking further into the future, I see that Microsoft will have to radically change licensing policies, even more so than they did with Business Ready. I see that licensing will be a concept of what he users uses, so you will buy 10 Credit controller CALs that will allow them access to AR, Customer, Excel, Outlook etc. The company may be running Navision, CRM and Great Plains in different divisions, but all the user will care is that they have a CAL that allows them access to the  Customer card.

But more importantly will be that there will be multiple VARs and multiple ISVs working together. There is no way that existing Navision VARs can deliver both the depth and breadth of technology that is needed, There will be many new opportunities for smaller VARs to go Vertical, and outsource all the components of the system, with them understanding he clients business needs, and relying on independent partners to deliver the components.

 
This is a great and exciting time for us. Get out there and look at the new technology that is coming at us. Knowledge of business process will be closely tied to the ability to integrate multiple technologies to solve issues, and we will rely less and less on the huge volume of customized code that we see now.

Will we go to bigger aircraft with Hubs and Spokes, or will we see 50 seat jets that can fly half way around the world non stop. And will we see more and more bespoke systems with lots of custom code, or will we see systems that integrate multiple systems into business solutions?