Andosi Blog - the Art of Great Design

Microsoft is finding success in the Enterprise Software Market

ERP Software Blog has a nice post up describing how Microsoft is finding success in the Enterprise Software space due in part to their shift to Azure cloud capabilities.

The Microsoft Dynamics stack isn't just for small and medium sized business.  We're seeing GP fit better and better in the enterprise space.  Don't rule it out when considering your next ERP.

This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.

5 Reasons to Re-Implement your Dynamics ERP

Are you frustrated with your Dynamics ERP system and starting to consider other options?  Maybe you feel like you have outgrown your Dynamics ERP system and need to move on to something like SAP.  Maybe it's just time to take a fresh look at your ERP strategy to take it to the next level.
Over the past few years we have completed several re-implementations of Dynamics GP for our clients while several others are considering the same in favor or moving on to something else.  Here are some reasons why they are choosing to re-implement.
1. Enable new revenue streams and growth strategies:
After completing a Dynamics GP implementation for a client in the early 2000s they recently changed their distribution strategy to include direct sale retail stores and have expanded the number of customer service centers.  During the initial implementation, neither was part of their strategy or a design consideration.  Their Dynamics GP workflow and integration customizations were not designed specifically to handle some of these new requirements.
We are now in the process of planning the re-design and implementation of some of their customizations.  With this new design, as they continue to expand their retail and service operations, on boarding these entities will be as simple as populating some setup screens on which their workflow, subledger to general ledger integration, and other system features will rely.  Long-term, as they continue their expansion, this will save them consulting services costs and make them more nimble.
2. Automate standardized business processes:
We spent a significant portion of last year re-implementing Dynamics GP for a client that was originally implemented in the early 2000s.  Since, they had further evolved and standardized their business processes as business process improvement and SOX compliance projects had been executed.  They evaluated their options and considered replacing Dynamics GP with a "Tier 1" system.  Through that evaluation they found that Dynamics GP could handle their requirements just as well for a fraction of the cost.
The result was a complete re-implementation of an integrated Dynamics CRM/GP system with a new custom application in between to handle product configuration.  The project was completed for considerably less than the estimate to do the same with a common "Tier 1" system with the same or better results.  They now operate their business free of disparate Excel spreadsheets, countless hours of redundant and unnecessary data entry, or years worth of hard coding implemented to quickly deliver on new or changing requirements.
3. Hodge Podge Syndrome: ERP systems are "evolutionary" not "revolutionary".  They grow, mature, and evolve over time as existing requirements are refined or more clearly understood and new requirements become known.  As this happens new functionality in the form of 3rd Party ISV Products, new modules or integrated technology, and custom developed solutions is implemented.  This is a common best practice that most often produces very good results.
Over time, if continuously reacting to an ever changing environment by implementing the first solution that appears to plug a GAP as quickly as possible, at the lowest possible cost you may end up with a variety of heterogeneous systems that don't integrate well or truly fit your requirements.  Common results of this approach include business rules hard coded into queries serving reports and a myriad of patches that have turned your off the shelf solution into a custom solution.
Taking the time to carefully and proactively consider new requirements and match them to the best available solution with consideration for how it interacts with the existing environment will prevent this problem.  If you don't, you may be sacrificing long-term continuity for short-term results.
4. The "vanilla", "out-of-the-box" approach left you with an incomplete system: While "vanilla", "out-of-the-box" implementations are less costly and completed more rapidly than full scale deployments they are often incomplete.  This is more commonly true for larger organizations.  Typically, customers assume that they can simply follow-up Phase I with future phases to layer on additional functionality.  This is not only true but is considered a best practice approach.  However, if you don't plan for future phases while designing your initial implementation you could be left with many GAPS to fill later.
If those GAPS are not few and far between you might be left with a square peg/round hole scenario in which you are consistently working around design decisions made without consideration of the future functionality required.  This is another situation where the software, if designed and configured around all of your business processes and requirements, will likely fit well.  If you do take this rapid approach with your implementation make sure to consider any known future requirements in your design to ease the implementation of that functionality later.

5. Your initial implementation just wasn't successful:
 
There are many reasons why ERP system implementations fail.  Inadequate requirements definition, inadequate customer and/or consulting resources, and unrealistic timelines or expectations are among some of the common reasons.  Typically, the primary driver of an unsuccessful implementation is not the software itself.
 
Often, unsuccessful implementations can be salvaged.  However, if the foundation is bad then you might be better served starting over.  Of course, now you would have the luxury of hindsight to determine why the initial implementation failed and correct that before starting over.  I would recommend you start by discussing this with your partner who has obtained the institutional knowledge to best ensure your success.  Of course, if they were the problem you might consider a change.
 
In summary, don't assume that changing ERP systems will solve your problems or get you where you need to go next.  You could very well have already purchased, many years ago, the ERP system that is best suited to run your business for many years to come.  Whether you are experiencing some sort of pain or simply have a new ERP strategy to implement I recommend you consider all of the factors involved in delivering a world class ERP solution and take the steps necessary to prevent the problems you might have to react to later.
 
This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.

Happy Holidays!

Happy Holidays everyone!

2010 has been great year for all of us at MBS Guru and Straight Arrow Consulting.  We recently wrapped up an integrated Dynamics CRM/GP implementation further evolving our Equipment Rentals Solution for Dynamics GP, are still working to help a client open a new Retail Store with an integrated Dynamics RMS solution, and are excited about all of the great projects, clients, and new products we are working with in 2011.

Check back for more posts from me, Bryan, and others after the first of the year.  As usual, we hope to grow to be more active in the community next year and expect to introduce a new MBS Guru contributor with a core competency around SharePoint soon.  We have a lot going on and are excited to share.

Cheers!

 

This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.

Register today for the 2011 Microsoft Dynamics GP Tech Conference

The 2011 Microsoft Dynamics GP Technical Conference is open for registration.  This Partner event is in Fargo again this year; March 1-3.  They haven't posted the agenda, speakers, or sessions just yet but I'm sure we'll see Dave, Mariano, and some other familiar faces with some new information for us.

 

This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.

Really???? Dynamics GP Report Writer is the Best Report Writer in the World?

Wow!  I never thought I'd have an opportunity to jump between Polino and Musgrave in a squabble but I just can't resist any longer.  Maybe they'll break out the sumo suits at Tech Conference this year and they can settle this debate once and for all.

I think Dave is just trying to get a rise out of Mark but I'll chime in anyway.  Like most, I lean towards the school of thought that Dynamics GP RW should NOT even be up for consideration as a the best in the world.  BUT, that's not to say it can't be great.

You can pretty much do anything you want with GP Report Writer as along as you have 1) intimate knowledge of the inner workings of GP and 2) know how to customize reports using VBA.  Dave demonstrates some of the advanced capabilities in his latest post on how Dynamics GP Report Writer is the greatest Report Writer in the World.  The problem is, there aren't many that would have come up with such a solution.

One cannot be a great Report Writer these days unless just about anyone can write reports with it.  Just about everyone is willing to stipulate that you cannot expect canned reports from any ERP system to meet all of your company's reporting and analytics requirements.  That said, the first question asked by most GP prospects about reporting capabilities is; "How difficult is it for ME to write new reports to my specifications?".  If not for SQL Server Reporting Services, and even Crystal Reports, this would be a much harder sell relying on Dyanmics GP RW alone.  Additionally, existing reports often rely heavily on temporary Dexterity tables that can make even seemingly simple changes to existing reports a challenge.

Finally, Dynamics GP has evolved so that RW is meant to be only one of many report writers available to GP customers.  GP does ship with a vast library of canned RW reports that most find to be extremely valuable in addition to a growing library of SSRS Reports.  Some companies hardly have to customize reports at all or develop new ones from scratch.  But, when you need to you can do so with RW or you can look to other widely available and commonly known tools such as SSRS and/or Crystal among others.

You can voice your opinion on the subject in Mark's latest Facebook poll.

We should celebrate the fact that we deliver and work with a system in Dynamics GP that ships with world class reports "out of the box" and a variety of common tools that enable you to customize or develop new reports from scratch on your own.

 

This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.

 

Microsoft Dynamics 10 eConnect C# 4.0 .NET Serialization In Memory

*Note* - This code was written for Dynamics GP 10. If you are using Dynamics GP 2010 see this updated article.
I was recently tasked with creating an eConnect integration between Microsoft Dynamics GP 10 and a custom SharePoint 2010 Portal designed to replace the GP Item Maintenance process with workflow and departmental routing.

 

Most of the eConnect examples I see online serialize the eConnect object to a file before loading it into an XmlDocument. This can cause unnecessary permissions concerns, and worse, if your application runs under the context of IIS or SharePoint you may not have a file system available to you at all. This was the case in my scenario. A much better approach is to serialize the object in memory.

 
Below is an example of eConnect serialization in memory using Microsoft C# .NET 4.0.
 
Assuming you have already installed the eConnect SDK 10, reference the following assemblies:
 
Microsoft.Dynamics.GP.eConnect.dll
Microsoft.Dynamics.GP.eConnect.MiscRoutines.dll
Microsoft.Dynamics.GP.eConnect.Serialization.dll
System.EnterpriseServices.dll
 
And add the following using statements:
using System.IO;
using System.Xml;
using System.Xml.Serialization;
using Microsoft.Dynamics.GP.eConnect;
using Microsoft.Dynamics.GP.eConnect.Serialization;
Here is the code to serialize the eConnectType object in memory and load it into an XmlDocument which is then passed to the eConnect_EntryPoint method:
 
string connectionString = string.Empty; // Set up a valid connection string.

eConnectMethods econnectMethods = new eConnectMethods();
eConnectType eConnectType = new eConnectType();

// Instantiate and populate the specific eConnect types needed.
// Don't forget to add them to eConnectType once they are set up.

// We're done building the object model, now serialize it in memory.
MemoryStream memoryStream = new MemoryStream();
XmlSerializer xmlSerializer = new XmlSerializer(eConnectType.GetType());
xmlSerializer.Serialize(memoryStream, eConnectType);
memoryStream.Position = 0;

// Create a new XmlDocument from the in memory serialized object model.
XmlDocument xmlDocument = new XmlDocument();
xmlDocument.Load(memoryStream);
memoryStream.Close();

econnectMethods.eConnect_EntryPoint(connectionString, EnumTypes.ConnectionStringType.SqlClient, xmlDocument.OuterXml, EnumTypes.SchemaValidationType.None, string.Empty);
 
Hope it helps!
This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.
 

Support Debugging Tool Build 14 released

The latest build of the Support Debugging Tool has been released by THE David Musgrave.  Check out the fixes, enhancements, and new features here http://blogs.msdn.com/b/developingfordynamicsgp/archive/2010/12/02/support-debugging-tool-build-14-released.aspx.

Ask your partner to download it for you now.

Thanks Dave.  Keep it coming!

 

This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.

Business Process Improvement with Conditional Process Holds in Dynamics GP Sales Order Processing

I was presented with a business process problem by a client related to managing Credit Limit overrides in Dynamics GP Sales Transaction Entry.  This company does not supply Order Entry users with the Credit Limit override password.  It's the Credit Manager's responsibility to decide whether or not to allow that override.
This client has been working for some time to generally route information to the right person that needs to make the decision and eliminate waste in their business processes.  During the normal course of business when users are presented with the "Please enter the credit limit override password:" prompt the Credit Manager is called to the user's workstation to make the decision on the fly.

 

This is a very inefficient process.  What a great opportunity for improvement!
To resolve this issue and get the information to the person responsible for making the decision while maintaining the system controls required we got creative with Process Holds, eConnect, and VBA with ADO.  Here's what we did:
First, we removed the "Exceed Credit Limit" password from Receivables Management Setup:

 
Now, users would have been presented with the more friendly prompt that would allow them to proceed without a password.
 
 
I don't claim to be a SOX expert but I'm guessing that wouldn't pass a SOX audit.  So, we added some VBA Code to the BeforeModalDialog Event behind the Sales Transaction Entry Window.  Of course, to make this work you would need to add that window plus the DocumentNo and the SOPTypeDatabase fields to your project.
 
 
 
The code calls the taSopUpdateCreateProcessHold eConnect stored procedure and adds the "CREDIT" Process Hold to the Document when the credit limit prompt appears and closes the dialog box by answering Continue to the prompt automatically.
 
 
Now, instead of stopping the user in their tracks to make this decision on the fly the Credit Manager can manage this Process Hold separate from the Order Entry Process.  To do this, we used SmartList Builder to build a SmartList that displayed SOP Documents On Hold.  Then, we added a Favorite with a Reminder to the SmartList to show only SOP Documents with the "CREDIT" Process Hold applied.
 
 
Now, when the Credit Manager logs into GP and periodically throughout the day he can quickly and easily analyze the Sales Orders for Customers that had exceeded their Credit Limit and manage them accordingly.
 
 
Get the right information into the hands of the person who is responsible for making the decision and you too can improve your business processes and efficiency.  It doesn't take much work or creativity to increase the ROI on your GP implementation using techniques such as this.
 
If you like this let me know.  If enough people do, maybe we'll produce a new freebie for Dynamics GP!
 
Don't accept what you're given, make it into what you need it to be.
 
This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.

Dexterity isn't going anywhere... anytime soon.

The topic of whether to execute a project by developing in Dexterity came up in a requirements discussion I had this week after The Dynamics GP Blogster and then Mark Polino opined on the subject.  I have spent some time thinking about this myself as we're also working on plans for 2011.  I don't think Dexterity is going anywhere as long as GP is around although it will continue to get depreciated over time.

When Microsoft purchased GP and consolidated ERP solutions under the Dynamics brand all the buzz was about both consolidating those solutions into 1 best of breed solution and/or replacing Dexterity with (insert your favorite .Net language here).  I don't even remember how long ago that was.  We're not really any closer to realizing either vision even though it's clear that .Net is the future for GP.

With the introduction of the Visual Studio Toolkit we're able to finally do some GP Development work in Visual Studio.  That's great but we still can't create Alternate Dynamics Windows or really modify existing GP windows in Visual Studio.  Dexterity still provides the tightest integration.  For some development projects, you just can't get around that.  I can't really speculate on how reasonable it is to expect that to change anytime soon.

Mariano makes great points in his IMHO post that it is basically (my opinion, not his) just not reasonable to expect Dexterity to be replaced by .Net unless GP is abandoned as a viable ERP solution.  The last I saw the Dynamics GP roadmap extended beyond v14 (2016).  When it comes to selecting a development tool for GP it's inevitable that Dexterity will rise to the surface as the best tool for some projects.  It's not always my first choice but sometime it is the best choice.  I don't foresee that changing anytime soon.

There's a good white paper on choosing the right development tool for your Microsoft Dynamics GP 10 Development Project.  http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a5b6c523-0add-48fd-9deb-2c0ef39b5673

This blog has been relocated from http://mbsguru.blogspot.com/ with authorization.



  • This email address is being protected from spambots. You need JavaScript enabled to view it.
  • (813) 792-1939
  • Privacy Policy