The Fury Group Way: Understanding Clients Through Design
•Download as PPTX, PDF•
1 like•314 views
The document discusses The Fury Group's approach to understanding client needs and designing solutions. It outlines basic steps for understanding, including documenting current and desired processes, and blueprinting current processes. Basic design steps include assigning objects to new objects and redesigning processes. An example scenario documents current siloed business applications and goals to sunset external systems and integrate Salesforce and NetSuite. Diagrams created in Lucidchart are used to document and design the solution.
Recommended
Recommended
More Related Content
Similar to The Fury Group Way: Understanding Clients Through Design
Similar to The Fury Group Way: Understanding Clients Through Design (20)
More from Lucidchart
More from Lucidchart (20)
Recently uploaded
Recently uploaded (20)
The Fury Group Way: Understanding Clients Through Design
- 1. The Fury Group Way
- 2. Introduction Eric Williamson CRM Advisor The Fury Group, LLC
- 3. What We Do ● Understand ● Design ● Build
- 4. Growing Pains ● Digital Transformation ● Bigger Projects ● Elegant Solutions ● Solving Big Problems PROBLEM: How do we fully understand what the client needs? How does the client know we understand?
- 5. Understand then Design Basic Steps for Understanding 1. Document current processes and applications 2. Document desired processes and applications 3. Blueprint / wireframe current processes 4. Group and consolidate by application (or role) Basic Steps for Designing 1. Assign old objects to new objects 2. Reassign or remove old processes 3. Architect and diagram desired processes
- 6. Scenario ● Three business applications ● All of the applications are siloed and require manual entry ● Goals: ○ Sunset external system ○ Migrate processes to Salesforce ○ Integrate Salesforce and NetSuite ○ Automate integration
- 7. Documenting 1. Sales closes Opportunity in Salesforce 2. Notification is sent that the sale was made 3. Manually create a Client record in external system 4. Manually create an Entity record in external system 5. Manually create a Contract record in external system ○ Auto-populate Contract #, Products, and Line Items 6. After Contract is created: ○ Notify PM for implementation ○ Manually create Invoice in NetSuite
- 8. Documenting 1. Sales closes Opportunity in Salesforce 2. Notification is sent that the sale was made 3. Manually Automatically create a Client record in external system 4. Manually Automatically create an Entity record in external system 5. Manually Automatically create a Contract record in external system ○ Auto-populate Contract #, Products & Line Items 6. After Contract is created: ○ Notify PM for implementation ○ Manually Automatically create Invoice in NetSuite
- 17. End Whether you think you can or you think you can’t, you’re right
Editor's Notes
- Here’s the basic outline that you should follow: Customer: Title slide Intro (speaker bio/company intro) (1-2 mins.) Main content (8 - 10 mins.) Problem to solve Lucidchart use case Who? What? Why? How? (Example diagrams)
- Who I am: Process oriented Background in sales, finance, non-profit management
- At the core of what we do is: Understand the business processes of our clients Design digital solutions to streamline and automate those processes Build those solutions on the Salesforce platform My role specifically is to understand and to design
- As The Fury Group and Salesforce have both grown, our projects have started becoming more complex both with what we The Fury Group have the capability to do, but also Good: Sign of digital transformation at the highest level Greater chance to build elegantly designed solutions Bigger projects for The Fury Group Which means we’re solving bigger problems We realized we had a problem of our own: How are we going to fully understand what it is our client is trying to do? More importantly, how are we going to make sure our client is comfortable with the idea that we understand what they’re trying to do AND we can do it?
- Basic Steps for Understanding Document current processes and applications Document desired processes and applications Blueprint / wireframe current processes Group and consolidate by application (or role) Basic Steps for Designing Assign old objects to new objects Reassign or remove old processes Architect and diagram desired processes
- Client is using the following business applications: Salesforce - Sales processes An external system - Project and Issue Management Netsuite - Accounting and Finance All of the applications are siloed and require manual entry Their goals are to: Sunset their external system Move all project and issue management into Salesforce Integrate Salesforce and NetSuite Automate the processes between Salesforce and NetSuite
- First, we needed to write out our client’s CURRENT processes in plain English.
- Next, we needed to write out our client’s DESIRED processes
- At that point I just started trying to visualize the process to understand. Linear wireframe / blueprint of the current process Easy to get bogged down in formatting and making it “look neat” Goal is just to get the process onto the page; it can be cleaned up later
- Determine the best way to group these items My goal is to ensure 1) I understand what the client's current process is and 2) that the client knows I understand Some cases it makes sense to group by role In this case it made more sense to group by the three business applications At each of these points I walked through the process again always trying to simplify the phrases in each box - ie “Sales closes in Salesforce” now that its in the Salesforce container, can just be “Close Sale”
- Ultimately I grouped it to where I could fully understand their process and it was “easy” to follow. Subdivided into the individual “objects” (imagine a business application as an entire Excel workbook; each individual tab or worksheet inside that workbook is a “object;” the only difference between an Excel workbook and a relational database like these is that each of those tabs or worksheets inside of that workbook are connected to each other and talking to each other)
- The final phase was to morph that current process into the desired process. First I simply removed the external system’s container and enveloped all of its processes with the Salesforce container because ultimately that’s where it would be.
- Next, I organized all of the object containers into an easy-to-read layout And I removed all (now) unnecessary manual processes
- After cleaning it up, I now had the basic process and necessary objects to build the overall flow At this stage we get the client’s verification that these should work
- The end result ultimately looks nothing like that previous diagram, but without it we couldn’t get here I combined several elements from two different diagram types (entity relationship diagrams and process diagrams). While this looks extra complicated, the fact of the matter is that it was. And without the ability to build out this diagram, we wouldn’t have been able to actually construct the orgs and the integration the way we needed to.