1. Sage ERP 1000 v4 Project Overview
Russell Slaymaker – Sage ERP 1000 Product Manager
Richard Aird – Sage ERP Business Analyst

2. Agenda
What is v4?
Project Overview
Explain some new functionality

3. Why?? What Version 4 is not It is not Sage 1000 v2.4
It is not a ‘tightly coupled’ integration
Why??

4. This is Sage 1000 v2.3 Advantages Dis-advantages
All contained within one application
Functionality from both systems available side by side
Dis-advantages
Every user requires both a CRM and ERP licence.
Unable to perform separate upgrades of either system
All patches from CRM and ERP require extensive regression testing due to heavy customisation.
Limited to Sage CRM, with no prospect of extensibility
Not aligned with Sage’s worldwide approach to CRM integration

5. What is Version 4 Advantages of this approach
Sage 1000 v4 is a loosely coupled integration of two standalone products using a Sage endorsed integration protocol
Advantages of this approach
Limited CRM customisation which allows quicker provision of service packs
As it uses a standard integration method all future CRM releases will be compatible with Sage 1000 v4, therefore easy upgrade of either system
More flexible licensing, customers can buy only a CRM or ERP licence depending on the users job role. Or both if necessary.
Potential to integrate with other CRM systems
It is aligned with the integration strategy of other Sage products (e.g. Sage 200, X3)

6. What is included in phase 1
Integration with Sage CRM
Use of Synchronisation for Customers; Suppliers and Commodities only.
Bespoke Functionality to handle converting Quotes to Orders
Clear documentation of operation including any limitations
Emphasis on enablement and supportability.
Only minor enhancements to ERP functionality

7. What is excluded from this phase?
Integration with SLX
Any requirement not considered a MUST
Explain exclusions due to quick release this year.
Decisions based on BP road shows conducted by Russell and Richard
Explain what we mean by MUST – i.e. cannot release without it as integral to our objective.

8. What are the Dates Development phase: April - June
R&D Testing: April - July
Support UAT: August
BP Beta: September
Release: October
Development already well under way.
Testing has also already started, ensuring the synchronisation development for the previous v4 is bug free, tests for new functionality has also been started
Support will be involved from August, hopefully some workshops, currently planning enablement
BP will have a version to test by September
Release scheduled in October, ***this will be a soft release limited to selected sites, which replaces an early adopter or hand held site.
Strong focus on Sage 1000 post release*** clarify

9. Process so far
Each stage we have collaborated with our product manager and others within the business (pre sales, CRM, SLX etc etc) to ensure we have agreement.
Mention how much we learned from the BP visits and how it recalibrated out views of what is important and what isn’t. It gave us some context as to how our customers work and gave us a clear differential between small companies and bigger companies and how they work.
Every user doesn’t do everything

10. The High Level Design has been split into two areas
Functional Requirements
Customer\Supplier creation and management
Lead, opportunity and quotation management
Sales order creation and order fulfilment
Non Functional Requirements
Licencing of Sage 1000
Supported platforms
Deployment

11. Functional Requirements Customer/Supplier Creation and Management
The system should ensure this information only needs to be entered once
The system should enable customer creation with all the information required to create an order at the first point of entry
Design Principles
Customer records can be created\amended in either CRM or ERP
Customer records will be synchronised between the two systems
The method will be SData synchronisation, adhering to the GCRM contract
Benefits
Uses established technology
Some development work already carried out

12. Functional Requirements Customer Creation and Management
Talk around this

13. Functional Requirements - Customer Creation and Management
SData Entities Synchronised
Not all attributes of the trading account is synched both ways, financial information is from ERP to CRM only

14. Linking an account in CRM
Link button standard CRM functionality, can continue without linking, leaving as a prospect or unlinked account.
Cannot use pricing service or convert a quote.
Mention the viable customer options also.

15. Linking an account in CRM
Once linked this is denoted by the chain symbol on the account, it is not possible to delink.

16. Functional Requirements - Customer Creation and Management
Development Priority
DEVELOPMENT CONSIDERED
MUST
SHOULD
COULD
Provide two way synchronisation between ERP & CRM X
Provide form popping in CRM to open accounts in ERP

17. Functionality prototyped but not part of this release phase
We could add additional functionality to the Link Accoun button……

18. Functionality prototyped but not part of this release phase

19. Functional Requirements - Customer Creation and Management

20. Functional Requirements Lead, Opportunity and Quotation Management
The system provide information that enables the creation of valuable marketing lists
The system should be able to record opportunities including probability of sale and estimated value
The system can create quotes that; calculate accurate prices; apply the appropriate discounts; have an expiry date and have an option to add a contact.
The system should allow quotes to be linked back to opportunities, leads and marketing campaigns.
The system should lend itself to quick entry of quotes
The system should provide a sales pipeline that includes details of unexpired quotes and opportunities

21. Functional Requirements Lead, Opportunity and Quotation Management
Design Principles
All lead, opportunity and quotation functionality is CRM only
CRM quotes will therefore be held in CRM only and not visible to ERP users
An improved pricing service is required for CRM quotes
Quotes should be able to deal with bundles*
The system should be able to convert a quote to an order keeping the integrity of the order details in place
Benefits
ERP will not be ‘cluttered’ with quotations
Quotes can be created without the need for an ERP customer record
As the quotation data is CRM side they can be included in the CRM sales pipeline
Quotes can be included in CRM forecasting
CRM quote entry mechanism is currently more streamlined than that in Sage 1000
There is a limitation here.

22. Functional Requirements Lead, Opportunity and Quotation Management

23. Functional Requirements – Leads, Opportunities & Quotes
SData Entities Synchronised
Explain prices – they are passed across but not used – technicality to do with CRM data model.

24. Functional Requirements – Quote Stock Check

25. Functional Requirements – Quote Stock Check

26. Functional Requirements – Quote Pricing
Two pricing options on a CRM quote line
Manually price the line
Use ERP pricing

27. Functional Requirements – Quotes Conversion
Couple of things to note, we can add free text line here and comment lines.
At this point we can save and leave as a quote or we can choose to convert to an ERP order.
Also note we can capture the customers PO number here if required.

28. Functional Requirements - Leads, Opportunities & Quotes
Once converted the CRM quote is locked and the ERP order number is passed back.
Important to note that the PO number and quote number have been passed to ERP and there is a new table to hold these details.
That is the end of the process for the CRM user, it’s now an order in ERP. This is one of the important things that we learnt from our BP visits, this is how most medium size companies work with a clear dividing line between the duties of the sales force and that of the back office staff.
Utilise actionable list in ERP to make this a powerful solution.

29. Functional Requirements - Leads, Opportunities & Quotes
Development Priority
DEVELOPMENT CONSIDERED
MUST
SHOULD
COULD
Convert a quote to a ERP sales order X
Rewrite pricing service to improve performance and quotes to be priced for non ERP customers
Provision of stock position within the context of CRM quotation
Provide form popping in ERP when a quote is converted
Explain provision of stock position

30. Functionality prototyped but not part of this release phase

31. Functionality prototyped but not part of this release phase

32. Functional Requirements Sales Order Creation and Fulfilment
The system should be able to check stock availability and allocate stock to an order during creation
The system should provide the user with various options when dealing with out of stock items, e.g. back order, split order.
The system should provide a full credit check of the customer and warn the user \ hold the order if the customer is on credit stop or will exceed their credit limit.

33. Functional Requirements Sales Order Creation and Fulfilment
Design Principles
All order creation and fulfilment, invoicing and payment functionality is ERP only
Sales orders will be available to view in CRM
Benefits
Reduces the size of the payload when running a synchronisation (especially the initial synch)
Uses rich ERP order entry functionality
Allows the same users to seamlessly create and despatch a sales order
No re-engineering of ERP functionality in CRM

34. Functional Requirements Sales Order Creation and Fulfilment

35. Functional Requirements – Sales Order Creation and Fulfilment
SData Entities Synchronised

36. Functional Requirements - Sales Order Creation and Fulfilment
Development Priority
DEVELOPMENT CONSIDERED
MUST
SHOULD
COULD
It must be possible to view orders within CRM X
Provide form popping within the CRM customer context to open ERP customer transaction enquiry
Provide form popping within the CRM customer context to open ERP sales order entry

37. Functional Requirements - Customer Creation and Management
Note there is also an option to create an order for this new customer, something we’ll come onto later.

38. Non Functional High Level Design
Non Functional Requirements
Licencing of Sage 1000
Supported platforms
Deployment

39. Sage 1000 Licencing Considerations
CRM users can create customers, quotations and sales orders without the need for an ERP licence
Any user that has a requirement to fulfil sales orders (e.g. print pick lists, despatch goods etc.) will need an ERP licence.

40. Supported Platforms Overall principle
Sage 1000 will be supported on all Microsoft platforms still under general or extended support at the time of release. However we need to understand the priorities for this release.
REQUIREMENT
MUST
SHOULD
COULD
Sage 1000 v4 supported with IE9 X
Sage 1000 v4 supported with Windows 8 (x86, x64)
Sage 1000 v4 supported with SQL Server 2012
Other exclusions
Windows server 2003????
Microsoft Server 2003 is not compatible with the integration technology and therefore it is only supported for v4 as a standalone.

41. Deployment Approach to upgrades from v2.3
Upgrades from Sage 1000 v2.3 will require a fresh installation of both products. It will not be possible to retain existing customisations.
Data conversion tools may be available, a detailed guide to conversion will be available.
Further details to follow