The Case for Mid-Market ERPs

"My company is going to be a billion dollar company in ten years, we should buy a tier 1 ERP right now!"

     I hope your company never makes that kind of decision. Tier 1 ERPs with broad strokes are really designed for giant sized companies, they are enormously complex systems. Consider x lines of reasoning in favor of your mid-market ERP.

The Money Advantage

     You may be trying to make the case that all of your competitors are using a tier 1 ERP for argument's sake we will use SAP for the balance of this post. Consider this, your competitors are likely much larger than you, thus the tremendous expense of maintaining an SAP environment is a smaller percentage of their profits than your Mid-Market ERP's cost. Further the annual support fees that you pay will be substantially smaller than for SAP. Staffing your IT team is also much less expensive.

     There is also a hidden cost in this decision. Since tier 1 ERPs are designed for large businesses that can absorb additional workers needed to take on additional roles that were unnecessary in your mid-tier aand likely customized ERP system.

The Cutting edge

     Tier 1 ERPs are, in my opinion never cutting edge anymore, in fact SAP feels like a glorified command line program they have grown out of a completely different era, and as a result the user experience is completely foreign to the new people entering the workforce. Mid tier ERPs like NAV have a more natural (and evolving) feel that are more intuitive to the how and why of working in in them. The training, memorization and mistakes from transaction
Based SAP have a cost that should not be overlooked.

Nimbleness

     The problem with giant ERPs is that like giant organizations they are not nimble. Making decisions, implementing changes are a long and drawn out process. As you look at your competition likely you recognize that if you can beat them to market with a new product, feature or service you will have an advantage. While it is true you might be able to do so while on a giant ERP solution, that speed will come at a much higher cost.

Internal brain trust

     The first thing an SAP guy will tell you is that no one knows all of SAP. That is true to an
Extent with any ERP but imagine you want to implement a process change that affects three departments in your company and so you approach your IT team. You discover that to implement your change you will need to enlist 3 area experts, a developer and a project manager. You can almost smell the money being burned there can't you? This is where a mid market ERP saves you realmtangible dollars. The same process in NAV may require one, maybe two resources 9 times out of ten.

     In conclusion, giant ERP is not evil, but it is not for everyone it is great at making giant organizations run well, but it can easily make your small/mid-sized organization run poorly and expensively. The next time you need to kill a fly use a swatter not a shotgun, you'll be happier with the results.

NAV Mail Issues

In NAV often times (depending on your user population) you may need to have NAV send emails based on an specific user action. NAV uses CodeUnit 397 (Mail) to serve this purpose. In my environment, we often need to send emails that are multiline. To facilitate this a minor addition can be made to the mail codeunit. I recommend adding a new function when this is necessary. This can be done by modifying a copy of the NewMessage function. I have listed the code below. Changed code is in RED. If you have questions, please feel free to post a comment.

Source:
Function Name: Typically I name this function NewMessageMultBody
Other Considerations:

• The Body Paramater should be changed to an array. The corresponding variable in any calling functions needs to be an array of the same size. I use 200 as my default.
• The CH variable is a CHAR giving it a value of 13 represents a carriage return.

NewMessageMultBody:

IF ISCLEAR(OApplication) THEN
CREATE(OApplication,TRUE,TRUE);

IF (NOT OApplication.Logon(TRUE,'','',FALSE,FALSE)) THEN BEGIN
OApplication.Logoff;
EXIT
END;
IF ISCLEAR(OSendMail) THEN
CREATE(OSendMail,TRUE,TRUE);

ErrorNo := 0;

OSendMail."To" := ToName;
OSendMail.CC := CCName;
OSendMail.Subject := Subject;
OSendMail.BodyFormat := 2;
MailGUIDValue := CREATEGUID;
OSendMail.SetUserProperty(GetMailGUIDFieldName,1,FORMAT(MailGUIDValue));

IF ISCLEAR(BSTRConverterBody) THEN
CREATE(BSTRConverterBody,TRUE,TRUE);

CH :=13;

BSTRConverterBody.ResetBSTR; // This code moved from within the below revised if. The process will not work if this code is not outside that IF
FOR X := 1 TO 200 DO BEGIN
IF Body[X] <> '' THEN BEGIN
Body[X] := Body[X] + FORMAT(CH);
BSTRConverterBody.AppendNextStringPortion(Body[X]);
END;
END;

OSendMail.Body := BSTRConverterBody;
IF ISCLEAR(BSTRConverterAttachFileName) THEN
CREATE(BSTRConverterAttachFileName,TRUE,TRUE);

IF AttachFileName <> '' THEN BEGIN
BSTRConverterAttachFileName.ResetBSTR;
BSTRConverterAttachFileName.AppendNextStringPortion(AttachFileName);
OAttachments := OSendMail.Attachments;
OAttachment := OAttachments.Add(BSTRConverterAttachFileName);
END;

OSendMail.OpenDialog := OpenDialog;
MailSent := OSendMail.Send;
ErrorNo := OSendMail.ErrorStatus;
OApplication.Logoff;

These simple changes will work along with Outlook 2003 as well as Outlook 2007.