Because we are implementing our system all of the time, this guide and its supporting content will continue to evolve. We’re continually trying to make the journey as simple, comprehensive, understandable and comfortable as possible for you and your team.
Everyone’s feedback is welcomed. What you tell us is valuable and will be followed up. And, typos will be happily corrected!!!
The Blueprint is about designing a solution, the solution is defined by your needs, the problems you want to solve and the improvements you want to make.
What’s in this guide?
You’ll get the most out of this guide if you read it in its entirety. It will help instill your ability to identify and understand how the business works, translate it into a blueprint design and present useful information to people in the business.
This guide will give you actionable insights into how to think about creating your Blueprint.
The Blueprint defines the design of the solution and how it will be built. The Blueprint is both the design and the plan. The design describes both what the solution will do and help you discover the benefits it will deliver.
The plan defines the tasks to ‘build’ the solution and who will do them. This is sometimes referred to as the ‘scope of work’ The timelines and amount of effort required is determined in the Build phase.
The output of the Blueprint phase is:
- Solution Vision: A top-level view in a document or a slide deck.
- Solution Design: The Salesorder platform, its configuration, and any ‘must-have’ enhancements (Plugins).
- Scope of Work: To build and run the Solution.
Decide upon a project leader
Getting the best out of everyone, and the best result for everyone should be foremost in the project leader’s style and approach. Soft skills as well as maintaining clear and timely communication are both critical.
Your project leader should be comfortable with; accountability, choosing, focusing and motivating the team, planning tasks, and setting and negotiating timescales.
The project leader should be given full management and financial authority to drive the project to a successful conclusion. They have to have outstanding attention to detail and patience.
Your project leader must be proactive and a completer finisher. The project leader should be a quick learner and have experience with relevant technology.
Remember this is a software engineering project, so a solid appreciation or experience with software systems, especially CRM, eCommerce, Logistics and Accounting is essential.
A sense of humor is mandatory….
Choose the team
If you work in or have worked with the business, or in a similar business you’ll know who the key players are in each strategic function of the business. They should be leaders, better still experts in their respective functions.
Remember you are creating a team, not an autonomous collective.
In these types of projects, there’s nothing more exciting than working with a group of talented people who proactively and openly communicate with each other and stakeholders to ask and answer the right questions.
It goes without saying, your team should be able to convince and enthuse other stakeholders.
When you’ve completed the Blueprint, communicate the vision and all the details you have to the entire team in one session.
Listen to feedback, and refine…
Divide the design of your solution into strategic functions
Salesorder.com enables joined-up thinking by empowering your teams to manage your sales, fulfillment and accounting operations in concert. It brings together all of the key parts of your business in a single system.
The objective of our system is to go beyond joining up the key parts.
Our system was deliberately designed to drive continuous improvements in productivity in each of the key parts. This is achieved by tuning and automating workflows.
Most of this is ‘out of the box’ and can be quickly extended or refined by customization. Salesorder.com is built from the ground up to be customized.
In the Blueprint, you’re starting with the vanilla Salesorder.com platform. Your objective is to confirm if the vanilla version is the solution to the majority of your needs.
Almost a minimal viable product if you will. Any additional functionality you need are ‘gaps’. These can be filled with customization or by third-party software.
The key parts of your business are sales, fulfillment, and accounting.
To simplify the challenge of identifying the needs of each of these parts, the sensible approach is to further divide these top-level parts into ‘strategic functions’.
How do you define the strategic functions?
At Salesorder.com we focus on business models that sell physical products business to business (b2b) and business to consumer (b2c).
These businesses either build/source stock, or don’t. Businesses that stock inventory either have their own warehouse or use 3rd party logistics (3PL).
Businesses that don’t stock inventory drop ship from vendor partners.The efficiency of the inventory’s journey from customer order to customer delivery is a target for continuous improvement.
Depending upon your business model this ‘inventory journey’ is underpinned by these strategic functions:
These strategic functions of your business have these common elements:
- Workflows: Processes
- Software functions: Components to manage the processes
- Reports: To track and measure the results of the processes
The strategic functions, their key features, and respective elements are the place from which you begin your thinking about what you want to achieve from the design of your solution.
Here are some examples to ignite your thinking, let’s start with Inventory:
Stock levels and the velocity at which the respective stock is sold and replenished directly affects your working capital.
If this is something you want to improve then you could define a strategic function of your design which focuses on ‘Inventory optimization’.
Similarly, if the accuracy, coherence, availability accessibility of the data about your product set is something you want to improve then you could define a strategic function that focuses on ‘one truth inventory’.
Inventory has now become two strategic functions for you to focus upon. These are both headlines for communications and projects in their own right.
I hope you can see they have a lot more meaning than just ‘Inventory’.
Here are a few more strategic functions you will probably want to consider:
- customer self-service
- order capture
- tracking SKUs in the supply chain
- warehouse optimization
- shipping automation
- accounts payable automation
- data warehouse
- reports and analytics
Defining and focusing on well defined strategic functions make the overall challenge easier, more interesting and ultimately intellectually and commercially more fulfilling for you and your team.
You should set simple and clear objectives for each strategic function. Focus on problems and explore every opportunity.
Use a SMART template (Specific, Measurable, Achievable, Relevant, and Time-Bound), to help you write objectives search Google, there’s an abundance of information on SMART.
To help you think about measurable objectives here are some examples:
- Turnaround Time
- Service Level
- Response Time
- Risk Management
These are all measurable 😉 One or more of them will be strategic thoughts i.e “Every Little helps”.
By 1995, as intended, “Every Little Helps” had become the driving philosophy that steered every initiative that Tesco made. “The challenge for us all is to make “Every Little Helps” second nature in everything we do. It’s more than just a line at the end of an advert.”
This is a legendary quote from Sir “Terry” Leahy, a British businessman, previously the CEO of Tesco, the largest British retailer and the third-largest retailer in the world measured by revenues.
Give each strategic function a simple title and unique identifier i.e ‘OC’ for order capture, SHA for shipping automation. Use these as suffixes on requirements tasks and their associated documents i.e. OC-1 ‘Set Freight terms’, where set Freight Terms is the title of the gap.
Discovering and evaluating the approaches and options for each strategic function will fine-tune your thinking. The result will be clarity about what you need and what you need to do to get it built.
The sum of the thinking about each strategic function will define what your business must have and the benefits it will realize from the design of the solution.
Every little helps. Every improvement adds to the overall sum of improvements. In each strategic function, there will be key features you should think about targeting for improvement.
You may already have some in mind (and probably the reason(s) that brought you here ). You might have a process or a strategic function in your business that’s working well. You’ll want to confirm you can incorporate this into your design.
Defining the tasks (and their owners) in the strategic functions
The most efficient method for defining the tasks in a strategic function is to begin by creating visuals.
A good example of visualization is the user story. The user story is a tool to capture and describe a software feature from the user’s perspective.
The user story describes the type of user, what they need and why they need it. (who, what, why).
Another example from a different perspective is the workflow. It makes it much easier to think about a workflow if its steps are visualized as opposed to being written out.
One more example, rules can easily be visualized with the right tools. Ideal candidates are order capture, shipping and commission rules.
Tools you can pick up, and start using to create visuals will both simplify and accelerate the process. They’ll also make it easy for you to communicate and share your thinking.
The easier it is for your audience to understand and give you their thoughts, the higher the probability of success.
For mapping analyses, workflows, processes, and plans out we use Mindmeister. For listing and managing tasks, specifically in the scope of work, use Monday.com.
We’ve created some useful templates for the latter. Both apps are in the cloud, so it goes without saying you can encourage everyone to get on the same web page(s).
Gather information, create tasks
Begin by creating a list of the core workflows in each of the strategic functions. This won’t be complete, as it will probably grow when you engage the key users.
Here are some examples to get you started:
Stage 1: Work with the key users and stakeholders to gather and visualize information about the current workflows, rules, and stories.
Use a Mindmeister mind map. Get all of the details into or linked to the map. Create online folders to organize and store documents. Link to these from the map.
As you go create high-level granularity task lists. Don’t be afraid of doing these on the maps. It’s probably easier to work around one screen. Talking of screens, get the biggest display you can to share the maps whilst you’re creating them.
One other trick, show the stakeholders how to use Mindmeister. Honestly, it takes five minutes. Then get them to do the mapping work.
Run the results by other stakeholders to validate or get more contributions.
Stage 2: Get into Monday.com, get your boards sorted. One board per strategic function. Keep your columns simple like this:
On each board, separate the work into logical groups of tasks. A group should have a single objective, for example:
Use Tags to classify documents, notes, and data i.e. #Reqs (requirements)
Wise ones who welcome change of course! Working with Individuals who know the way things work and get done can be a good and bad thing.
Look out for “I’ve always done it this way” (I’m not going to change or think ‘outside the box’). Tricky one this, you’ll need to get them on side eventually. Whether you do it now or in the ‘Build’ phase is your call.
Focus on getting into the detail of what they do now. If they don’t offer any initiative to improve things, get the current detail and move on. Be prepared to have to sell the new way to them.
Read ‘It’s Human to sell’ by Daniel Pink if you’re intimidated by selling a better way to folks.
If you’re fortunate to get a ‘wise one who welcomes change’ then extract every last drop of value out of them. Ask yourself, is this a key user? However, don’t take them at face value.
Get to know them in this phase, work with them for a while then decide at the start of the ‘Build’ phase if they are going to be one of your ‘Key users’.
Quiz what they know about the big picture. Where else have they worked in the business, how long have they been there? Where did they work before? What did they work on? What skills and knowledge do they have?
We’re honestly surprised how many folks we work with don’t know how useful they are until asked.
Users and stakeholders need to see and touch functionality to build their knowledge and confidence. Whilst you’re working through your analysis the first priority is to educate the Key users.
Before you take this step you should have mapped (documented) and made a task list of the key workflows in the respective strategic function. You’ll need to refer to these as you prepare to show them anything.
You should begin by showing Key users’ Salesorder’s core generic workflows in the context of their respective roles. To do this you need a sandbox instance.
We can create this for you in a few minutes, just ask. To make the sandbox useful you’ll need to import some data from their current data sets.
Don’t overthink this.
Just make sure you accurately set the user’s expectations. Explain you are setting up and going to use a sandbox or ‘demo’ system to walk them through core workflows relevant to them.
Be clear there will be ‘gaps’.
For the core workflows, you will need the following settings and data types in the sandbox. Import or enter them manually in the following order:
Before you engage with the Key users, refer to the relevant map and work through the respective core workflow by yourself in Salesorder, just to make sure everything you need to demo the core workflow is as it should be.
All good? Engage one or more of the relevant Key users. Keep in mind Key users are new to Salesorder, so encourage questions. Remind them, “the stupid questions are the ones they are afraid to, or ask”.
Based upon what you know so far about how they currently run this workflow, make sure you are prepared for the “What about?” or “Where is?” or “How does?” questions.
The ideal place to begin is the core workflow, Sales Order capture to Payment (order to cash).
As you walk through each step of the workflow, record key questions and answers, you’ll need these for training the wider audience of users.
Identify and understand gaps, gather requirements
As you model and walk through each workflow, you may discover what we refer to as a ‘gap’. A gap is a need for additional functionality.
Debate each gap with the Key users, and record the key points. You’ll need these to write up the description of the requirements.
Create a group on Monday.com for the requirement. Give the requirement a prefix and meaningful title i.e. OC-1 ‘Set Freight Terms’. (OC = Order Capture). We’ll work with you to make sure the requirements have all of the detail we need to address the gap.
There are at least seven possible solutions to a gap. It can be:
- An undiscovered or alternative method or workaround,
- An existing plugin which exactly fits the need,
- An existing plugin which can be modified to address the need,
- A new plugin can be developed,
- An integration with third-party software,
- On our engineering roadmap,
- A custom report.
Whatever it is, we’re a software engineering business and can most probably devise a way to fill the gap.
List and gather samples of reports
Before you begin, it will save you a lot of work to know Salesorder has List as well as Reports. Keep this in mind. We often find a significant portion of the current reporting activity can be done in the Lists.
You should have created a Monday.com board ‘Reports and Analytics’.
Reports are common to most strategic functions and will be produced by the same set of reporting tools.
List all of the key reports as in their respective strategic function Groups on Monday.com. Make each report a Group. Start the Group with a requirements task.
Your objective must be to create effective reports which answer business questions clearly and concisely.
As you work with key users modeling the core workflows for each strategic function, ask them to give you a list and samples of the reports they use or need or a regular basis.
Ask key users about what answers they get from the reports, add these answers to the infobox against each report requirements task.
Make notes about the key purpose and parameters of each report. Pay attention to the classification of data.
Good examples are the segmentation of Customers by their lifetime value to date, or a parameter commensurate with their location. If your old system’s reporting uses any forms of classifications (a.k.a Classes) in Sales, Inventory and most probably Accounting, then record and review these.
Look out for any unusual filters, structures or formats and note them down. Use the ‘info boxes’ section on each Task to record your notes.
Use the ‘Add files’ control to upload/attach the report samples. To access these, simply click on the Task to open the sidebar window.
Consider how many Excel spreadsheets are in use in your business and why? Make a list and gather them into a folder. Now, look at how you can reduce these, what can be done in reports and what you can learn from their users.
However, keep in mind:
- You can export all reports and Lists (from Salesorder) to Excel.
- Excel has an OLAP connector.
- Salesorder has an OLAP connector (contact support).
Microsoft says, “Online Analytical Processing (OLAP) is a technology that is used to organize large business databases and support business intelligence.
OLAP databases are divided into one or more cubes, and each cube is organized and designed by a cube administrator to fit the way that you retrieve and analyze data so that it is easier to create and use the PivotTable reports and PivotChart reports that you need.”
If your business has multiple legacy systems, make sure you list both the source and the method (commands/actions) you used to generate each report. This is really important as it will save time when you and others do deeper analyses or comparisons.
What Data where and why?
Salesorder is a transaction processing system. It processes and stores transactions between your business and your trading partners (Customers and Suppliers).
These transactions are created by users (workers), by your sales channels, or by the system itself.
Every transaction relies upon, collects and generates specific types of data. Each transaction is an ‘event’ in your business.
In your legacy system and Salesorder there are broadly two types of data; Master and Transactional:
To accelerate and simplify the user’s journey to understanding and using Salesorder, we call ALL transaction and master records ‘Documents’.
The most common strategy for migrating data from a legacy system to Salesorder is as follows:
1. Essential Data
You can import data into Salesorder using the Import Sheet Templates. These can be found in SETUP > Import Data.
For each type of data, there is a corresponding template. Each template has instructions. There is guidance in the column headers to help you determine the format and syntax of the data.
See the Build documentation for detailed instructions and guidance.
If you are transitioning from a Legacy system, these are the data types you should import for the system to be at a minimum state to proceed with Live operations.
Essentially, standing data is data that does not often change, i.e. names and addresses
Live posting Documents are transactions in the general ledger with a Status of ‘Open’ or Partially Paid i.e. Sales and Purchase Invoices, and any advance payments.
Live non-posting Documents i.e Sales and Purchase Orders with a Status of ‘Open‘ or ‘Partially fulfilled’ (Sales Order) or ‘Partially Received’ (Purchase Order).
To complete the transition, you’ll need to deduce and enter the opening balances for all P&L and Balance sheet accounts in Salesorder.
2. Optional Historical Posting data
You should as far as it is possible try to mitigate the need to move historical accounting data. The easiest and most risk-free option is to preserve the accounting data in your old / legacy system.
You should carefully consider what types of retrospective views of your financial data you need going forward. Make a list of who needs them, what type they need, why, when, how often, and to what level of detail.
You should also decide how far back in time you want to go.
Get down to the fine grain on this, pin stakeholders down on the questions they will need to ask of the historical data.
Imagine the cut-over to a new system happened in December 2019, examples might be:
- Show me a comparison between June 2019 Sales and July 2020 sales
- Show me gross margin on this product since July 2019
- Show me sales by-product over the last three years
You might be surprised how short your list of questions like the ones above becomes. A very short list should signal you to carefully consider just how much thought and effort you really need to put into organizing the future of your historical posting data.
You could ask the question, could you get what you need from non-posting data? For example, Total Revenue for a period, and Revenue by customer could be derived from historical Sales Orders with any Status of ‘fulfilled’ being migrated to the new Salesorder system.
You could also get Sales by Line Item (SKU) from this data set, and report on historical profitability if you pursue this approach.
The answers to the above questions will help you decide what data you need, where it should reside and how much effort and cost you should expend.
If you decide to pursue a strategy of relocating any of your historical accounting data, you should give the following points serious consideration:
- Accounting databases have at least three levels of complexity, their schema, the data stored in them and how careful the users were who put it there.For example, records of explanations about extraordinary transactions. Keep in mind accounting is about explanations. The foundation of a good explanation is a set of facts. In accounting, the facts are the accounts and the transactions against those accounts.
- The task of extracting, transforming and loading (ETL) to a new system can easily exceed by a significant order of magnitude the time and costs of other parts of your project.
- How far back you’ll want to go with historical reports and analysis will drive the volume of data you need to move. The volume you have to move and check will be significant.If you’re moving from Quickbooks you will probably know the bigger the company file, the higher the probability it will have corruptions.
- The risk to the eventual integrity of the accounting data.
- The ROI. How often will this data be referred to?
- The real and actual level of ‘regulatory risk’ you could expose the business to if you don’t retain a copy of or access to the old system. For obvious legal reasons, you should avoid being in this position.
3. Optional Historical non-posting data
Historical non-posting data is in sales and purchasing documents. The key documents are:
The Status of each type of these historical documents should be carefully considered. For example, Orders with a Status of ‘Fulfilled’ vs ‘Partially Fulfilled’.
The benefits for Sales operations
“Get them, know them, keep them”. Insight to each customer’s buying pattern, profitability and lifetime value (LTV) are essential to driving sales focus and productive selling behaviors.
If the common and recurring questions from salespeople are “What sales of what products did we forecast from them, what products did we quote them, what products did they order?” then historical non-posting data should be in, or within easy reach of Salesorder.
These insights can be used to drive the design and timing of marketing campaigns, pricing decisions, and product development. The aggregation of your entire sales history can be used to decide planning and budget assumptions.
The benefits of purchasing and Inventory optimization
Stock purchases make demands on your working capital. The timing, quantities, and values of your stock purchases are driven by current and forecasted demand.
Apart from product lead times which are driven by three factors; vendor’s current stock availability, time to manufacture and transit times. The data you need to feed into your predictions is in your sales and purchase order history.
These obvious benefits justify the case for storing your historical non-posting data in a place where you can slice, dice and analyze the data to find and answer what are arguably your most important questions.
Where to put historical non-posting data?
The decision about where you store this data depends upon the level of rigor and the frequency of your analysis.
There are three options:
What is a data warehouse, and what are the benefits?
A data warehouse is designed to answer the questions being asked throughout the business every day, questions not focused on individual transactions but on the overall process.
A data warehouse is always subject-oriented as it delivers information about a theme instead of an organization’s current operations. A data warehouse can be organized as a federation of subjects i.e. Sales, Inventory.
This strategy gives users a clear perspective within the boundaries of a specific theme by eliminating data not required to answer the user’s questions.
In order to meet this requirement, the design of the data warehouse must directly reflect the way the teams in your business will look at the business. If it does not, it will not be easy to answer their questions.
This characteristic lies at the heart of the data warehouse. It distinguishes the data warehouse from the transaction processing system and requires a design based on an entirely different set of principles.
If your previous (legacy) systems consisted of a number of databases, then you can see combining these in a single data warehouse would serve the ‘joined-up thinking’ requirement.
As previously stated, avoiding transforming accounting data from one proprietary schema to another is high risk and difficult.
Rather than attempting to transform the accounting data in its entirety, it’s a lot easier to take sections of this historical data set into a data warehouse.
What sections you take are wholly driven by the questions you’ll need to ask of this data and its non-posting counterparts.
What was the value of the balance sheet on a specific date, is not a question you would ask of a data warehouse. Neither would you ask “Show me the profit and loss for the business over a specific period?”.
Accounting software is complex and designed to answer these accounting specific questions. We do not contend that this complexity is unnecessary, only that it complicates the analytical tasks of business.
Sorting out and simplifying the contents of the accounting system is a worthy goal for a data warehouse.
Accounting is just one part of the overall order to cash process. Focus on the sections that you need for the questions.
For example “Show me the converted or lost sales for a particular product category in a given region, or to a specific customer or show me what is profitable and what is not are better suited to the data warehouse.
Where can you read more: https://learning.oreilly.com/library/view/data-warehouse-design – love this book.
Where to create the data warehouse?
This very much depends on the volume of data and the frequency and complexity of analysis. This coupled with how comfortable you and the business are with the nitty-gritty of database design is going to determine your strategy.
These are your options:
Build a data warehouse within the Salesorder database system (software stack) but outside the Salesorder database schema.
- If simple, it’s quick to build, and therefore cheap. It’s a great starting point.
- We’ll help you qualify if it’s the right approach and if it does it for you.
- Not scalable (in terms of complexity) and therefore has a short horizon of practicality if your needs expand.
- Contention for system resources
Build your own standalone data warehouse using a suitable platform i.e. AWS or Azure. Both software stacks optimized for Data Warehouse applications.
- A well-trodden path, plentiful user experiences, and lessons in the vendor’s ecosystems.
- Will scale
- Not expensive to get started (if you know what you’re doing)
- Documentation is like reading a book through a straw because it’s aimed at developers.
- Steep learning curve, even to deduce your options and where to start.
Cost of verified skill-set & real experience
Use a third-party data warehouse application i.e. Snowflake.
- Very focused solution
- Vendors will have relevant working examples and knowledge
- Inexpensive ‘pay for what you use’
- Availability and cost of verified skill-set & real experience of the newest platforms.
First priority – fast-tracking visible results to build confidence
The overall purpose of implementing a new system is to make everyone’s life better and increase business performance. The system will solve old problems and introduce new opportunities.
The system is a tool. People have to use it to understand, extract and apply its value. You have to carefully expose them to it, get them engaged and build their knowledge. Knowledge creates confidence.
The people involved and affected by the project, are used to the way it is before the project begins. Every individual will have their own perspective on what they or the business needs.
Use the Blueprint phase to gradually educate everyone.
Before you begin showing folks the system or talking about the solution, take time to get to know people and get to know and understand what they do in detail. Master their dictionary of terms and their meanings.
Look out for quick learners and individuals you ‘connect’ with. Observe how they connect with others. The ones who do this positively and consistently are probably good candidates for your Key users.
You need at least one evangelist. Don’t compromise or be biased by their seniority or lack thereof. You need individuals who are already well versed in selling to or getting their way with their co-workers.
Engage Key users as quickly and as early as is possible. Share this Blueprint with them. Start by walking them through top-level overviews, specifically What’s in Salesorder? and basic, relevant workflows i.e. create a Customer, Sales Order, Shipment, Sales Invoice.
Then let them play and explore. Get them to send their questions to us, if you can’t provide answers.
Make sure you precede their exploration with this reassurance :
And of course “Salesorder.com is a software engineering business (not a product company with commission-hungry salespeople)”. Honestly, we‘re here to listen and think.
Like you, we’re looking for a long term, intimate and complementary relationship with mutual benefits. This takes time…
Regardless of how simple it looks, or what vendors promise, it’s so easy (and common) in any software there are going to be hurdles.
Incomprehension, unexpected behavior, inconspicuous controls, vague instructions. All of these lurk in the shadows waiting to frustrate or halt users.
These ‘speed bumps’ coupled with the user’s expectation that the app will work like they are used to working are the realities of introducing a new system. We’re biased of course, but in our experience, Salesorder is up there with the easiest to use of apps in its class.
Patience, one and all, learn the conventions; List, Document, Action, Inheritance, you’re at least halfway there in minutes.
Encourage, encourage, encourage; Key users to show and share their learnings and results with their coworkers.
There’s a lot to think about, a lot to decide and a lot to do. You’re deploying a solution that will underpin the strategic functions of the business for arguably and at least the next 5 to 10 years.
Take your time. Talk to us as often or for as long as it is practical. Run your ideas and your Blueprint by us.
If you’re struggling, or stuck or would just like to hand the whole thing over to us we’re ready to help.
When you and your team are happy and you have completed your Blueprint, the next step is the ‘Build’ phase. We’ll see you there.