consulting rate

ara3n

DenSter wrote:

The biggest issue with making fields mandatory is that you can use records in so many places that you'd have to set Items up for everything before you could use them. Why would you want to make Item Tracking code mandatory if you don't use Item tracking? Why would you make Production BOM number mandatory if you don't use manufacturing?

By the way, all we've seen is screenshots of NAV 5. We have no way of knowing how many fields are on the form. As far as I can tell there are just as many fields, possibly even more, hidden under the bands.

I was using the field just as an example. In most companies, Items is create by person A and used by Person B.

All I was pointing about is that the fields on Sales Order are not in the same they are on v4. There is a reason why they've changed them, usability and making it simpler.

What I am trying to do is, just because people are not agreeing with Miklos, doesn't mean that he does not have valid points.

DenSter

I am saying you don't know about the fields in NAV 5, because I don't think you have seen the actual table design. If you don't know about the fields, I don't think you should make comments about how they have changed.

I never said Miklos didn't have a valid point, I just don't agree with it.

ara3n

You are right, that I don't know the table structure for Navision in v5.
I did not stated that. All I said about was the user sees a lot less fields on a sales order. Hence the SO screen is userfriendly.

Miklos_Hollender

David,

you surely have some points about mandatoryness, but I think you don't take everythink into account. For example, I always had to prepare weekyl time reports - in the popupar Time@Work software at my first job and a custom-made Delphi one at my second job, which was initially made for service technicians and just superficially customised to fit consulting... Both of the time I hated it. I hate it, because, first and foremost, administration is always a horrible boring work. Second, because both software lacked that kind of user-focused helper functionality that f.e. copying the last week or setting a week 5*8 hours to holiday with a single click etc. and a missing of such features is a typical mistake of most ERP systems I've ever met. (Nav, Ax, SunSystems, SAP B1, Compiere, TinyERP, MFG/PRO). Therefore, of course, I used every bug I managed to find as excuse on why not to fill the time report - the general way of thinking being that if I'm forced to do something I hate, then at least it should work 100% properly. I think I'm a naughty user But most users I met have been similarly naughty. Which is quite understandable. In the good old times, administration clerks were doing all such things. But now, we are forcing salespeople who sell $5M a year to waste their precious time on entering phone calls into CRM systems and so on. I don't agree with this strategy but I never was able to talk clients out of it. So, the only thing we can and MUST do is to make ERP/CRM whatever systems into being really good. Really good means a typical data entry task must not be longer than a minute, and users be able to do it with only a minimal amount of attention, and it means the software must catch all possible errors and even make suggestions on how to correct them. Spending $10000 on saving five $5M salespeople 30 hours a year each is generally good biz (this just for being ontopic ) and a lot few installations would end up in chaos if all the manager of the clients would understand this simple equation.

The situation in most of my projects was the following. The company was using a simple operations system - usually based on Access or one of those typical one-programmer Clipper or Visual FoxPro small systems of the past. The users were mostly content with it, because it had only a few fields, very simple data entry process and actually, you can get used to anything after a few years. The basic problem was that the managers hated it, because they could not get information necessary for running their biz. So the decide to implement a real ERP. But the problem is, more information always means more data entry, no matter how integrated the software is. (Actually, the ERP II concept i.e. integration to custmer/vendor systems could help it a lot, but it's damn expensive.) Therefore, there is always a user-resistance, and overcoming it is actually one the most important factors in the success of the project. Now, all the talk about "change management" and so I think does not only work in real life - I think people cannot be talked into liking something that's not really good for them. All we can do is to do a lot of changes to make the transition process at least bearable. And one of the most important changes are enabling users to pay less attention to usig the software, enabling them to think "well, if it accepted the data entry, it must be correct". Which is actually a natural way to think. If there are standards to follow, such as entering Posting Groups to master data record, then it's quite a natural requirement of users that the system should not accept the record without them. I can completely understand it. It's the same idea that f.e. if you have an USB device and you managed to stick it into a port in your computer, then it must be an USB port. You don't have to figure out which one is the USB port, you can trust the computer to not allow you sticking it into any other ports. It's the same idea, the same need.

Yes, flexibility is important in the long run. But to survive the first year of using the system, I think it must be stricter than SAS training Then the restrictions can be gradually removed later on, if necessary.

I have a story. I participated in the later crisis management of a badly blown MFG/PRO implementation. Shipments and other inventory transactions needed to be interfaced to financial system for invoicing and G/L posting. Therefore the Customer records needed to exist in both. They were connected through VAT Registration No. As the field was not set mandatory, it missed in 70% of the records. This turned out to be the most important source of the crisis - salespeople don't giving a f**k about this field because they were bonused for sales, not for administration and then the IT trying to hastily fill these fields by hand at each run of the data export/import. You can imagine the results. So, this is a clear example of why just telling people "please don't forget this field" won't work.

Miklos_Hollender

Deadlizard,

For example, look at how successful Incadea is, 500+ installations of a car retail add-on that has completely nothing to do with standard Navisions. How many companies you know who mostly sell standard + small customizations have more than 50 clients? All those famous, big-name users Toyota, Minolta, Adidas have at least 80% a custom-developed system.

The dangerous misleading is Microsoft telling it's partners that they can be successful by selling the standard with small customizations. If an inexperienced team - such as an SBS/ Exchange / Office -reseller who wants to widen it's product portfolio, it happens often - gets into Navision and they believe the functionality present to work properly and please users just because "it's standard, it must be good", they get into big trouble. I have personally seen four well-financed, big partners going broke just because believing Navision is a finished product. And on the other hand, I see small, underfinanced partners doing really well by importing and localising good add-ons, for example, the magnificent ENWIS garbage-management add-on. ( http://www.tegos.de/produktbroschueren.html ) My life was a constant suffering until I realized I need to drop customizing standard features and instead build add-ons and glue them on the General/Item Journal level, so, building "skins" for Navision, at least. And then everything started to make sense and became easy. It was a great enlightement.

Alex_Chow

Microsoft never stated that Navision should be used out of the box. However, if a company really wanted to, they can use it out of the box. It's far stretch, but still possible.

Navision is marketed as an entry level ERP system to medium small businesses. My opinion is that it's very fitting. Compared to the customization of what is needed from SAP/R3, Navision is a breath of fresh air.

Miklos_Hollender

But THIS is the error. Why on Earth would anybody compare NAV to SAP R/3 when even implenting SAP Business Warehouse (same stuff as BA for NAV) is usually 100-150 days, and it's just a smaller of their two products (the larger is Data Warehouse) and therefore it's for really huge companies with lots of money to spend? Why not compare NAV to those $10.000 Access-based small systems these companies used before, which are limited in functionality and especially in business reporting functionality, but take about 5 days to implement?

On the other hand, NAV is not a typical SMB system. The reason it is not so is that it's simply too complicated for that. Typical medium-business system, rather that. For a company that can spend beyond the usual licence and implementation price, spend, say, $100 000 for two add-ons (one operational, one controlling-related) or for 120 days of development. For them, it's perfect.