SYSTEM PROPOSAL
Prepared for Shield Boards, LLC
Nathan Adler, Steven Asifo, Marissa Goon,
Vicky Lee, and Lesley Zhang
BMGT407 | Section 0101| Dr. Ibrahim | May 9, 2014
Table of Contents
Executive Summary..……………………………………………………………………………………...…… 3
Survey Phase Report………………………………………………………………………...………………… 6
Client and Industry Background……………………………………………………...………………6
Problems, Opportunities, and Directives…………………………………………...……...……..7
Project Scope………………………………………………………………………………………………….8
Project Objectives..………………………………………………………………………………..………..8
Constraints……………………………………………………………………………………………..…...…9
Gantt Chart………………………………………………………………………………………………..…10
System Analysis Phase Report.…………………………..……………………………………………….11
Questionnaires……………………………………………………………………………………...…......11
Interviews…...…………………………………………………………………………………………........11
Sampling….……………………………………………………………………………………………...…...12
Data Flow Diagrams……………………………………………………………………………………..13
Project Proposal Report….………………………………………………………………………………….18
Data Flow Diagrams.……………………………………………………………………………...……..18
Synchronized System Models (CRUD Matrix)...…………………………………………........27
Physical System Design.………………………………………………………………...…………...…28
Input and Output Design…..……………………………………………………………...…………...35
Implementation Plan..………………………………………………………………………...………...41
Lessons Learned…………………………………………………………………………………………..42
2
Executive Summary
Abstract
The focus of our project with Shield Boards, LLC, a startup company at the
University of Maryland, is to complete a detailed system analysis that will determine
the appropriate design for our proposed new system. Throughout the semester, our
team, UMD Systems Consulting Group, have examined the current system and
documented our proposal progress during our survey phase, analysis phase, and
system proposal phase.
Survey Phase Summary
In the survey phase, we investigated the company’s background to discern the
primary shortcomings of the current system. Through our research, we determined
that the scope of the project would entail implementing Customer Relationship
Management (CRM) software in order to enhance tracking of customer records. As
our end users were undergoing a complete operations migration from an established
system to an unorganized and unestablished system, plenty of time was spent on
attempting to organize customer data and ensure that the data was accurate. We
found this inefficiency to be an opportunity for our group to improve upon.
By discovering Shield Boards’ primary frustration with their system, we
identified the prime objective of our project. Once this was accomplished, we
determined our project objectives and constraints. By increasing efficiencies of the
system, we aim to reduce the turnover time from three weeks to one week, evaluate
customer experiences with the company to enhance customer relations, and measure
the total of returning customers to determine customer loyalty with our new system.
Shield Boards will also be able to aggregate their customer data into financial reports.
The constraints we may face include economic, legal, schedule, technical, operational,
and cultural constraints.
3
Analysis Phase Summary
In the systems analysis phase, we utilized several information gathering
techniques to generate precise data flow diagrams. The primary methods include
questionnaires, interviews, and sampling, which allowed us to more accurately design
the data flow diagrams of the current processes and the desired future processes.
By questioning the customers of Shield Boards, we were able to determine
their needs and what improvements would accommodate these. This information is
crucial for the company because it is still pre-production and is only handling
preorders. Once the company completes production and enters full production in
January, they will able to consider our proposal and possibly implement our customer
relations proposal.
We were also able to conduct an interview with the CEO of the company, Chase
Kaczmarek. Through our discussion, we were able to gain a thorough understanding
of the current systems, inquire about potential weaknesses in the system, and discuss
possible improvements for the customer-ordering and payment processes.
Finally, we sampled the forms and reports that result from customer input on
Kickstarter, which proved to be tremendously useful. We looked at the Kickstarter
Backer reports located in the software and the exported Excel spreadsheets of
customer data. From this information, we knew what information was needed from
customers and allowed us to determine the data flows of the system and the different
data stores required.
System Proposal Phase Summary
In the system proposal phase of our project, we closely looked at the possible
candidates for our system. We considered three solutions: an in-house solution using
Microsoft Visual Basic .NET and SQL Server Management Studio, a hybrid solution of
Intuit Quickbooks Online Package for Financials and Microsoft SQL Server
Management Studio, and an Enterprise Package SalesForce Sales Cloud.
After comparing the solutions through a candidate systems matrix,
cost/benefit analysis, and a feasibility analysis, we have decided on our proposed
4
system that is detailed in the Conclusions and Recommendations of our report.
Accompanying our new system proposal are the physical dataflow data diagrams, our
input and output design, implementation plan, and lessons learned.
Conclusions and Recommendations
After looking considering the three possible solutions, we propose Shield
Boards implement the in-house solution with Microsoft Visual Basic .NET and
Microsoft SQL Server Management Studio. This system would computerize financial
reporting and a customer relationship management system, fully supporting the end
user requirements while maintaining control and security over sensitive information.
This solution has the highest scores for economic, operational, cultural, and technical
feasibility. Although this method will take the longest at 6 weeks, the method is the
best suited for Shield Boards because of its high feasibility, ease of implementation,
and low cost.
5
Survey Phase
Client and Industry Background
Shield Boards, LLC is a startup company that sells Wheel Shields, a patented
longboard skateboard accessory that provides a solution for the primary safety
problem longboarders face. Wheel Shields are aluminum wheel covers that prevents
riders from turning too hard and accidentally hitting their wheel, which often leads to
a detrimental fall. Founder Chase Kaczmarek, a Robert H. Smith School of Business
student, conceived the idea for Wheel Shields in July 2012. In the spring of 2013, he
competed and won first place in Pitch Dingman and MTech’s Business Model
Challenge. In August 2013, the founder and co-founder, Vicky Lee, successfully raised
$31,000 in a Kickstarter crowd-funding campaign in order to bring Wheel Shields to
mass production by January 2014. The company has secured retailers and
distributors of Wheel Shields in Sweden, Canada, the United Kingdom, the
Netherlands, and Hong Kong and has sold pre-orders of Wheel Shields worldwide.
During this time, the company took orders on the Kickstarter website and manually
recorded orders from retailers on Excel spreadsheets.
Currently, the company is migrating from the Kickstarter system to their own
new system, and is taking orders on their website. They initially kept track of orders
by creating Excel spreadsheets, but have very recently implemented a Shopify system
on their website which kept track of orders on the system since the beginning of
December. Even with the improved system, the company still has records of their
orders on Kickstarter, multiple Excel spreadsheets, and Shopify. Managing orders on
so many different systems is proving to be very difficult for the company’s users.
Longboard skateboards are longer skateboards with larger, softer wheels that
easily allow skaters to gain speed and glide. Longboards are growing in popularity
because of their incredible versatility; they can be used for doing tricks, downhill
racing, or commuting. The US skateboarding market is worth $70 million and the
international skateboarding market likely exceeds $140 million. By 2016, the
industry is expected to grow 6.5%. Longboard sales are included in these numbers,
but the exact percentage is unknown. Industry surveys conducted by ActionWatch, an
6
extreme sports market research firm, indicate that between 2009 and 2010,
longboard sales increased by 43%, demonstrating the strong positive trend. Shield
Boards, LLC has sold over 500 sets of Wheel Shields in two months in pre-orders and
the company anticipates a high influx of orders once it launches the finished product
in January 2014.
Problems, Opportunities, and Directives
After talking with the founder and president of Shield Boards, Chase
Kaczmarek, our group discovered various potential risks and opportunities for the
company’s exponentially growing database systems. Since the company is still in its
initial phase of operations and has not yet reached the production stage, there is a
lack of customer relationship management software that can store necessary client
information. It is a good business practice to emphasize customer retention and
provide customer support. Building a personal marketing strategy that is based on
the customer relationship software and previous order data can provide
individualized updates and recommendations to customers.
Since Shield Boards does not have an accessible database to collect and
analyze this data, it is more difficult for them to track customer purchase orders and
relay that information to inventory items as well as production orders. By
implementing an appropriate information system and software, the executives at
Shield Boards can instantly track customer information and orders, as well as access
production schedules and inventory amounts. Another benefit of such a system
would be providing existing customers with similar products and easier repurchase
options for the future. Not only will this reduce time for the company, but it will also
make the process more efficient for the customers. We believe that this is an
opportunity for Shield Boards to not only address the issues common to startups, but
also to take advantage of the flexibility of the company before the production process
and information system become active.
7
Project Scope
The scope of the project includes implementing Customer Relationship
Management (CRM) software in order to better keep track of customer records. The
software will include tracking customer information and orders, accessing production
schedules and inventory amounts, and providing existing customers with similar
products and easier repurchase options for the future. The project will include
integration of CRM software with the Kickstarter and Wheel Shields websites, which
will give access to production, order processing, and customer information. The
software will produce reports of what customers are purchasing and when Shield
Boards has been in contact with certain customers in order to manage customer
relations and provide efficient processes for the future. CRM requires all customer
data, including their personal information and purchasing history, previous
interactions and communications with customers, production schedules and
inventory amounts, and the types and pricing of products Shield Boards offers. Notes
can be added to customers’ files when communication occurs between employees
and customers. The project will be completed in approximately two months and will
be tested in early December before Shield Boards launches their finished product at
the end of the year. The system developers will be involved in the completion of the
software and the co-founders will approve the software and test it. The project will
not only focus on improving customer service, but also improve sales for the
following year by attracting new customers.
Project Objectives
The objective of this project is to improve efficiency and customer
relationships. By creating a system that will better collect the data, processes can also
be improved to ensure efficiency and relationships are maintained. We will be able to
assess the success of the system by looking if the process time from a customer
placing an order to him receiving the item is reduced at all. Ideally the creation of this
system will allow the process to run quicker and better improve the supply chain and
logistical aspects of the company. For orders within the United States, our goal is to
8
reduce the turnover time from three weeks to one week; this estimate includes the
time it takes from receiving the order, checking the inventory, shipping the product,
and the customer receiving the item.
Another way to evaluate the success is to reach out to existing customers to
see if they feel the system has improved their experience with the company and if the
repurchasing options or suggested items matched their preferences. By surveying
existing customers we can better evaluate whether or not the system truly benefits
the customers and improves their experience. Finally, we will measure the amount of
returning customers as well as loyalty from new customer experiences with our
system. This way we can ensure that we are reaching new customers while still
attending to existing customers. We hope this database will help maintain customer
retention at 70%, since it noticeably increases customer satisfaction. The goal to be
efficient while improving customer relations can easily be measured once the system
is implemented.
Constraints
The end products that we plan to deliver to Shield Boards are customer
relationship management software and an inventory management system. In
delivering these final products there are several obstacles and limitations that we
foresee. Shield Boards is a fairly new company that has only handled presales, so to
an extent, we are not fully aware as to how much volume this system should be able
to handle at one time. Depending on the needs of the company we will be able to
determine the level of sophistication of the software and systems. A higher level of
sophistication may be out of the reach of our team since we lack computer
programmers. Another limitation that we foresee is that, since the company is still
starting out, we will need to make sure the implementation fits the overall aim of the
company, such as whether it should be mobile or have access across multiple
platforms. Overall there is a time constraint to the point where Shield Boards actually
starts production and selling Wheel Shields. We imagine this time frame to be three to
four months from the initiation of our project.
9
We will adjust to these constraints by keeping an open line of communication
with the client in order to discuss possibilities for future roadblocks. We will also
communicate any limitations that are larger than the scope of this project to our
professor in order to get suggestions on how to pivot our objective, if need be.
Gantt Chart
10
System Analysis Phase
Questionnaires
One of our main objectives in creating the system is to ensure that we are
improving customer relationships and experiences. Creating a questionnaire is a cost
efficient and convenient way to survey our customers while allowing them to
maintain anonymity. This ensures that the information we are collecting is accurate
and unbiased. Two types of questionnaires were distributed, one to new customers
and one to existing customers. New customers were provided with a short survey
after they placed an order through Kickstarter. Customers would rate on a scale of 1being least favorable and 5- being most favorable on how well they liked the service,
how easy they found it to navigate, and how likely they would be to place an order in
the future. This provided us with a general sense of what new customers thought
about our current system and what areas we could improve. Currently customers will
get an email when they make a pledge through Kickstarter. They are charged through
Amazon and are also sent a reminder email if their payment did not process.
Customers did appreciate the reminder email, but wanted a more structured form of
communication so that they know when their order is approved, when the payment is
received, and when the product is shipped. In creating our new system, we will set up
a process so that the customer is notified when the payment is approved as well as
when the shipment and order is confirmed.
Interviews
Another fact-finding technique that we found effective was interviewing the
founder, Chase Kaczmarek, among other executives of Shield Boards. Vicky Lee, our
group member and current COO of Shield Boards, is able to provide our team with
significant insight into the company’s current strategies and operations; however,
talking with Chase Kaczmarek helped our group better recognize the company’s
future goals. By better understanding the company’s growth strategy and the change
in platforms from Kickstarter to the implementation of their own database system,
we are able to more suitably design a software and system that could achieve the
11
company’s goals. From the interviews, we were able to more accurately design the
data flow diagrams of the current processes as well as the desired future
processes. We were also able to inquire about potential weaknesses in the system as
well as possible improvements for the customer-ordering and payment
processes. Our strong, personal relationship with Shield Boards will definitely be
beneficial in future phases of the project, as well as with the physical implementation
of the system after the course.
Sampling
We also conducted a sampling of the forms and reports that result from
customer input on Kickstarter, which proved to be extremely helpful. We looked at
the Kickstarter Backer reports located in the software and the exported Excel
spreadsheets of customer data. Backers are the individuals who have pledged a
certain amount to help the company. We were able to acquire the actual copies of
these reports and familiarize ourselves with what attributes are used to describe
these individuals. The attributes in the database consisted of a backer ID to uniquely
define each backer, the name of the backer, their email and shipping address, and the
information related to their pledge to the company. This is synonymous with the new
customerId and information. This pledge information consists of the pledge amount,
if rewards have been sent, the pledge date, and the tier in which the customer is
located, which is based on the amount pledged. Viewing the customer data reports
helped us understand what information Shield Boards currently gathers, will need
from their customers, and what will be useful for them. This also helped us establish
and evaluate the requirements of the new system. Moving forward, we now have the
information needed from customers to help us determine the data flows of the system
and the different data stores required.
12
Data Flow Diagrams
Context Diagram
Context Diagram
In the Context Diagram, there are three external entities in the current system for Shield
Boards.
External Entities are:
 Customer: This external entity represents the individuals that will be ordering
the product.
 Shield Boards: This external entity represents the company that will be
requesting reports from time to time for inventory and other financial analysis
purposes.
 Amazon Payments: This external payment will be responsible for processing and
approving the customer’s order should the payment be approved.
Below are the Shield Board Ordering System inputs and outputs.
System Inputs:
From Customer:
 Customer Information
 Customer Order and Payment
From Shield Boards:
 Reports Requests
13
From Amazon Payments:
 Approved Payment/Customer Order
System Outputs:
To Customer:
 Receipt and Shipping Confirmation
To Shield Boards:
 Generated Reports
To Amazon Payments:
 Pending Payment
Level-0 Diagram
14
Level-0 Diagram Inputs
1. Add Customer Record
The customer will first log in to Kickstarter and provide their information. Kickstarter
will find the customer record from the Kickstarter Customer Database, based on the
customer information given, and the customer will be logged into the Kickstarter
account. If the customer record cannot be found, Kickstarter will add the customer
record, creating a new account, and store the customer record in the Kickstarter
Customer Database.
Process Inputs:
From Customer:
 Customer Information
Process Outputs:
To Kickstarter Customer Database (data store):
 Customer Record
2. Find Customer Record
The customer will input their customer order payment information into Kickstarter.
Kickstarter will store the payment information in the Customer Database, or find the
customer information if the customer has previously created an order through
Kickstarter before. This database stores the customer’s identification number, first
and last name, email address, country, customer’s address information, if the
customer is domestic or not, shirt size, and payment information.
Process Inputs:
From Customer:
 Customer Information
From Kickstarter Customer Database (data store):
 Customer Record
Process Output
To Process Customer Order:
 Customer Information
3. Process Customer Order
The customer then goes to the Shield Boards’ Kickstarter web page. The customer
identifies how much he or she would like to pledge. The amount the customer
chooses to pledge determines the product tier package. Kickstarter pulls the product
tier information from the Tier Database and the customer information previously
inputted in order to process the customer order. The Tier Database stores the
products in each package, the price associated with each package, the colors
associated with each package, and the amount of each package available if it applies.
15
Process Inputs:
From Customer:
 Customer Order Payment
From Find Customer Record:
 Customer Information
From Tier Database (data store):
 Tier Information
Process Outputs:
To Email Customer Receipt/ Shipping Confirmation:
 Total Amount Due
To Amazon:
 Pending Customer Payment
4. Email Customer Receipt and Shipping Confirmation
Kickstarter then processes and sends the pending customer payment to Amazon
Payments. Amazon Payments is a third-party entity that has its own processes in
processing customer orders and payments. Amazon Payments sends approved
customer order into Kickstarter’s Order Database. The Order Database captures the
following attributes: the identification number of the order, the identification number
of the customer, the pledge package purchased, shipping address, billing address,
total amount due. The “Process Customer Order” process flows the total amount due
information into the “Email Customer Receipt/Shipping Confirmation” process. Other
information that flows into the “Email Customer Receipt” process are the customer
record from Kickstarter’s Customer Database and the order information from
Kickstarter’s Order Database. This process then emails the receipt to the customer
and shipping confirmation to the customer.
Process Inputs:
From Process Customer Order:
 Total Amount Due
From Kickstarter Customer Database (data store):
 Customer Record
From Order Database (data store):
 Order Information
Process Outputs:
To Customer:
 Receipt and Shipping Confirmation
16
5. Generate Reports
Shield Boards’ management can send requests for sales reports, which are generated
by pulling sales orders from the Order Database. The “Generate Reports” process
sends the compiled sales information to the Backer Database, which sends backer
information to the “Generate Reports” process. The Backer Database stores the
following information: total sales, total new customers, total number of customers,
and total pledge packages sold. The “Generate Reports” process then returns the sales
orders reports and backer reports to Shield Boards’ management for analysis.
Process Inputs:
From Shield Board:
 Requests for Reports
From Order Database (data store):
 Sales Order
From Backer Database (data store):
 Backer Information
Process Outputs:
To Shield Board:
 Reports
To Backer Database (data store):
 Completed Sales Information
Entity-Relationship Diagram
17
Project Proposal Phase
System Models of the New System
Context Diagram
Context Diagram
In the Context Diagram, there are two external entities in the current system for Shield
Boards.
External Entities are:
 Customer: This external entity represents either individuals that will be ordering
the product
 Shield Boards: This external entity represents the company that will be
responsible for processing the orders and sending receipt and confirmation to the
customer. Shield boards also may request reports from time to time for inventory
and other financial analysis purposes
Below are the Shield Board Ordering System inputs and outputs.
System Inputs:
From Customer:
 Customer Information
 Customer order and payment
From Shield Boards:
 Requested Reports
System Outputs:
To Customer:
 Receipt and Shipping Confirmation
To Shield Boards:
 Reports
18
Level-0 Diagram
Level-0 Diagram Inputs
1. Find Customer Record
The customer will first visit the Shield Boards’ website and then log in by providing
their information. Shield Boards’ website will find the existing customer record from
its Customer Database, based on the customer information entered, and the customer
will be logged into the existing account.
Process Inputs:
From Customer:
 Customer Information
From Customer Database (data store):
 Customer Record
19
Process Outputs:
To Process Customer Order:
 Customer Information
2. Add Customer Record
If the customer record cannot be found or does not exist, then a new customer record
and account will be created and the information will be stored in a customer record in
Shield Boards’ Customer Database. This database stores the customer’s identification
number, first and last name, email address, country, customer’s address information,
if the customer is domestic or not, shirt size, and payment information.
Process Inputs:
From Customer:
 Customer Information
Process Output
To Customer Database (data store):
 Customer Record
3. Process Customer Order
The customer then selects which Shield Boards’ products and items he or she would
like to purchase, and then the order can be processed. Shield Boards pulls the
product information from the Product Database and the customer information
previously inputted in order to process the customer order. The Product Database
stores the products that the company offers, the price associated with each item, the
colors associated with each item, and the total amount of inventory of each item
available.
Process Inputs:
From Customer:
 Customer Order
From Find Customer Order:
 Customer Information
From Product/Item Database (data store):
 Product Info
Process Outputs:
To Verify Customer Payment:
 Customer Order
4. Verify Customer Payment
After processing the order, the customer order flows to the “Verify Customer
Payment” process where Shield Boards then verifies the pending customer payment
using PayPal, which can approve all of its online orders. Shield Boards then sends the
approved customer order into its Order Database and emails the customer a receipt
and the shipping confirmation information with the total amount due as well as other
customer and order information. . The Order Database captures the following
20
attributes: the identification number of the order, the identification number of the
customer, the products purchased, shipping address, billing address, and the total
amount due.
Process Inputs:
From Customer:
 Customer Order and Payment
From Process Customer Order:
 Customer Order
Process Outputs:
To Order Database (data store):
 Approved customer order
To Email Customer Receipt and Shipping Confirmation:
 Payment Information
5. Email Customer Receipt and Shipping Confirmation
As Shield Boards sends out the receipt and shipping confirmation, the customer’s
purchase history is updated in the Customer Database so that both parties can access
previous purchase information. The information that flows into the “Email Customer
Receipt/Shipping Confirmation” process is retrieved from Shield Boards’ Customer
Database and the order information from the Order Database.
Process Inputs:
From Verify Customer Payment:
 Payment Information
From Order Database (data store):
 Order Information
From Customer Database (data store):
 Customer Information
Process Outputs:
To Customer:
 Receipt and Shipping Information
To Customer Database (data store):
 Customer Information
6. Generate Reports
Shield Boards’ management can also send requests for sales reports, which are
generated by pulling sales orders from the Order Database. The “Generate Reports”
process sends the updated and compiled sales information to the Sales Orders
Database, which sends customer purchase and order information to the “Generate
Reports” process. The Sales Orders Database stores the following information: total
sales, total new customers, total number of customers, and total items sold. The
“Generate Reports” process then returns the sales orders reports and customer
reports to Shield Boards’ management for analysis.
21
Process Inputs:
From Shield Board:
 Requests for Reports
From Order Database (data store):
 Sales Order
From Sales Orders Database (data store):
 Customer Information and History
Process Outputs:
To Shield Board:
 Reports
To Sales Orders Database (data store):
 Completed Sales Information
Level-1 Diagram: Verify Customer Payment
Level 1 Diagram
This diagram represents the Verify Customer Payment process, which can be divided
into three processes.
4.1 Receive Customer Payment
Once an order is processed, the system will verify the customer’s payment. The
system will receive the order from the Process Customer Order process and then
receive the payment from the Customer. The information will be then sent to the next
process, Process Customer Payment.
Process Input
From Customer:
 Customer Order Payment
From Process Customer Order:
 Customer Order
Process Output
To Process Customer Payment:
 Payment Information
22
4.2 Process Customer Payment
Once the payment is received, it will then be processed in the system. Once the
payment is processed it will be sent to the next process, Approve Customer Payment.
Process Input
From Receive Customer Payment:
 Payment Information
Process Output
To Approve Customer Payment:
 Processed Payment Information
4.3 Approve Customer Payment
Once the payment information is processed, the order will be approved and send to
the Order Database. The payment information will be sent to the next process, Email
Customer Receipt and Shipping Confirmation.
Process Input
From Process Customer Payment:
 Processed Payment Information
Process Output
To Email Customer Receipt and Shipping Confirmation:
 Payment Information
To Order Database (data store):
 Approved Customer Order
Level-1 Diagram: Email Customer Receipt and Shipping Confirmation
Level 1 Diagram
This diagram represents the Email Customer Receipt and Shipping Confirmation
process, which can be divided into three processes.
23
5.1 Pull Approved Customer Order
Once the payment is approved and the order is processed, the system will pull the
approved order. The order will then be sent to the next process, Create Order Receipt
and Shipping Confirmation.
Process Input
From Customer Database (data store):
 Customer Information
From Order Database (data store):
 Order Information
From Verify Customer Payment:
 Payment Information
Process Output
To Create Order Receipt and Shipping Confirmation:
 Approved Customer Order
5.2 Create Order Receipt and Shipping Confirmation
Once the order is pulled, an order receipt and shipping confirmation will be created.
Once the notification is complete, it will be sent to the next process, Email Order
Receipt and Shipping Confirmation.
Process Input
From Pull Approved Customer Order:
 Approved Customer Order
Process Output
To Email Order Receipt and Shipping Confirmation:
 Order Receipt and Shipping Confirmation
5.3 Email Order Receipt and Shipping Conformation
The created notification will be sent to the customer as well as a record will be sent to
the customer database of the customer order.
Process Input
From Create Order Receipt and Shipping Confirmation:
 Order Receipt and Shipping Confirmation
Process Output
To Customer:
 Order Receipt and Shipping Information
To Order Database (data store):
 Customer Order
24
Level-1 Diagram: Generate Reports
Generate Reports
Level 1 Diagram
This diagram represents the Generate Reports process, which can be divided into
three processes.
6.1 Pull Sales Information
When there is a request for a report, the system pulls the sales order information
from the Order Database as well as customer information and history from the Sales
Order Database. That data is then forwarded to the next process, Format Sales Data.
Process Input
From Order Database (data store):
 Sales Order
From Sales Orders Database (data store):
 Customer Information and History
Process Output
To Format Sales Data:
 Customer Information, History, and Sales Order
6.2 Format Sales Data
Once all the information is pulled, it is then aggregated and formatted for production.
Once the data is properly formatted, it is then sent to the next process, Print Report.
Process Input
From Pull Sales Information:
 Customer Information, History and Sales Order
Process Output
To Print Report:
 Aggregated Data
25
6.3 Print Reports
After the data has been formatted and aggregated, the report will be prepared for
distribution. It will be sent to the external agent, Shield Boards.
Process Input
From Format Sales Data:
 Aggregated Data
Process Output
To Shield Board:
 Reports
Entity-Relationship Diagram
26
Customer
.CustomerId
.fName
.lName
.Email
.AddressLine1
.City
.State
.PostalCode
.Domestic
.shirtSize
.PaymentInfo
Backer Database
.reportNo
.reportDate
..totalSales
..totalNewCustomers
..totalBackers
..totalPledgePackagesSold
Order
.orderID
.billingLine1
.city
.state
.postalCode
.totalAmountDue
Product
.productID
.price
.color
.quantity
..amountAvailable
C
C
C
C
C
C
C
C
C
C
C
C
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
Generate Reports
Email Customer Receipt
Verify Customer
Payment
Find Customer Record
Add Customer Record
CRUD MATRIX
Process Customer Order
Synchronized System Models (CRUD Matrix)
R
R
R
R
R
R
R
R
R
R
U
U
U
U
U
U
U
CU
C
CRU
CRU
CRU
CRU
CRU
R
R
R
R
R
RU
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
27
Physical System Design
Candidate System Solutions Table
In-House
Portion Of System
Computerized
Benefits
Software Tools
Needed
Application
Software
Method of Data
Processing
Quickbooks +SQL
(Hybrid)
Financial
Quickbooks Pro 2014
reporting and
Package for
customer
Financials and Inrelationship
House SQL Database
management
for Customer
system.
Relations
Fully supports
Creates estimates
user required
and invoices,
business processes download
with a customized transactions, built in
user interface.
reports, track sales
Maintain control
and expenses,
and security over
maintain control
all sensitive
over customer
information.
information
MS Visual Basic,
SQL
SQL
Custom Solution
Package Solution and
SQL
Client/Server
Client/Server
SalesForce (COTS)
Purchased
Enterprise Package
SalesForce Sales
Cloud
Complete CRM
system, Salesforce
mobile app, content
library, customizable
reports, opportunity
tracking, workflow
automation. Solution
can be quickly
implemented
Online Cloud
Package Solution
Client/Cloud
Feasibility Analysis Matrix
Weighting
Description
Operational
Feasibility
15%
In-House
Create inhouse system
using VB.Net
and SQL
Server
Database
Fully
Supports
user-required
functionality.
Score: 100
Hybrid
Quickbooks and inhouse SQL Server
database
COTS
Purchase
commercial offthe-shelf package
through
SalesForce
Fully Supports
user-required
functionality with
the exception of
opportunity
tracking for
customer relations.
Fully supports
user-required
functionality, but
concerns over
security.
Score: 90
Score: 85
28
Cultural
Feasibility
10%
No
foreseeable
resistance.
Score: 100
No foreseeable
resistance, but may
take time to adjust
to the Quickbooks
template.
Score: 90
Technical
Feasibility
15%
Schedule
Feasibility
20%
Economic
Feasibility
30%
Legal
Feasibility
Ranking
10%
100%
Solution
requires
writing
application in
VB.NET and
creating the
database in
SQL server
database. The
availability of
programmers
with
experience
with SQL and
VB is
relatively easy
to find, and
clients have
SQL and VB
experience.
Score: 90
6 weeks
Score: 70
NPV:
$77,305.95
Score: 100
No
foreseeable
problems
Score: 100
92.5%
Solution requires
creating the
customer database
in SQL server. The
availability of
programmers with
experience with
SQL is relatively
easy to find, and
clients have SQL
experience.
Quickbooks has a
limited online
support resource
and a locator for a
nearby expert in
Quickbooks.
May have few
reservations after
using the
Kickstarter
service, and
change in
interface.
Score: 85
Extra charges for
support on Sales
Force. There is a
24-hour phone
line for tech
support only if
the Premier
Success Plan is
purchased. Basic
training is
provided to get
user started and
online case
submission with
delayed response
and solutions.
Score: 65
Score: 80
3 weeks
1.5 weeks
Score: 85
NPV: $74,850.77
Score: 90
NPV: $63,294.64
Score: 90
Score: 80
No foreseeable
problems
No foreseeable
problems
Score: 100
Score: 100
86.75%
65.75%
29
Sales Force Cost/Benefit Analysis
One Time Initial Costs:
Setup and Configuration
Project Management
Training (2 classes)
Total Initial Development Costs:
$3500
$1,000
$4500
$9000
Projected Annual Costs
Annual Subscription Fees (for 2 users)
Service Support Fees
Total Annual Costs:
$3000
$1200
$4200
Benefits of SalesForce
Increased Sales Productivity (36%):
Maintenance Savings:
Efficiency Savings:
Total Annual Cost Savings:
$7050
$4500
$12000
$23550
COTS
(SalesForce)
System
0
1
2
3
4
5
Development
Cost
$(9,000.00)
Annual Cost
$$(4,200.00)
$(4,200.00)
$(4,200.00)
$(4,200.00)
$(4,200.00)
Cumulative
Adjusted Cost $(9,000.00) $(13,200.00) $(17,400.00) $(21,600.00) $(25,800.00) $(30,000.00)
Benefits from
the System
$$23,550.00
$23,550.00
$23,550.00
$23,550.00
$23,550.00
Time
Adjusted
Benefits (4%)
$$22,644.23
$21,773.30
$16,935.38
$16,284.02
$15,657.71
Cumulative
Adjusted
Benefits
$$22,644.23
$44,417.53
$61,352.91
$77,636.93
$93,294.64
NPV
$63,294.64
Hybrid System Cost/Benefit Analysis
Developmental Costs
One Time Initial Costs:
Setup and Configuration:
QuickBooks Online:
Microsoft SQL 2012:
$1500
$149.97
$249.95
30
Personnel Costs:
Programming Costs (600hr/$30):
Training Costs (30hrs/$20) :
Total Personnel Costs:
Total Development Costs:
$18000
$900
$18900
$39699.86
Annual Operating Costs:
Estimated Quote:
Total Annual Costs:
$2500
Benefits of Customer System
Subscription Savings:
Increased Work Efficiency Savings:
Employee Salary Savings (initial savings):
Annual Cost Savings:
Hybrid
(Quickbooks and
SQL) System
Development
Cost
Annual Cost
Time Adjusted
Cost(4%)
Cumulative
Adjusted Cost
Benefits from the
System
Time Adjusted
Benefits
Cumulative
Adjusted
Benefits
$2500
$3000
$12000
$20000
$15000
0
1
2
3
4
5
$(20,799.00)
$-
$(2,500.00)
$(2,500.00)
$(2,500.00)
$(2,500.00)
$(2,500.00)
$-
$(2,403.85)
$(2,311.40)
$(2,222.50)
$(2,137.00)
$(2,054.82)
$(20,799.00) $(23,202.85) $(25,514.25) $(27,736.75) $(29,873.75) $(31,928.57)
$40,000.00
$40,000.00
$15,000.00
$15,000.00
$15,000.00
$15,000.00
$15,000.00
$14,425.08
$13,868.34
$13,334.95
$12,822.06
$12,328.91
$54,425.08
$68,293.42
$81,628.37
$94,450.43
$106,779.34
NPV
$74,850.77
Custom System Cost/ Benefit Analysis
Development Costs
One Time Initial Costs:
Visual Studio 2013
Microsoft SQL 2012
$499
$209
31
Personnel Costs:
Programming Costs (800hrs/$30hr)
Training Costs
(40hrs/$30hr)
Total Personnel Costs:
Total Development Costs:
$24000
$1200
$25200
$25908
Annual Operating Costs:
Estimated Quote:
Total Annual Costs:
$1200
Benefits of Customer System
Service Support Savings:
Subscription Savings:
Increased Work Efficiency Savings:
Employee Salary Savings (initial savings)
Annual Cost Savings:
Custom System
NPV
Development
Cost
Annual Cost
Time Adjusted
Cost (4%)
Cumulative
Adjusted Cost
Benefits from the
System
Time Adjusted
Benefits
Cumulative
Adjusted
Benefits
NPV
$2000
$1200
$3000
$12000
$40000
$16200
0
1
2
3
4
5
$(25,908.00)
$-
$2,000.00
$2,000.00
$2,000.00
$2,000.00
$2,000.00
$-
$(1,923.08)
$(1,850.11)
$(1,778.00)
$(1,709.61)
$(1,643.85)
$(25,908.00) $(27,831.08) $(29,681.19) $(31,459.19) $(33,168.80) $(34,812.65)
$40,000.00
$16,200.00
$16,200.00
$16,200.00
$16,200.00
$16,200.00
$-
$15,576.00
$14,977.81
$14,401.74
$13,847.83
$13,315.22
$40,000.00
$55,576.00
$70,553.81
$84,955.55
$98,803.38
$112,118.60
$77,305.95
32
Rationale:
Operational Feasibility examines how well a solution meets the system
requirements. Because the company is at an extremely early stage, there is a complete
absence of an independent system for Shield Boards. The system requirements are
fairly general: to improve efficiency and customer relationships. It is essential that the
system meets these requirements for Shield Boards to continue to grow in the right
direction from its starting point. Improving efficiency and customer relationships at
ground zero, when there has been no previous implementation, will not be as crucial
as other measures of feasibility, therefore operational feasibility has a weight of 15
percent.
Cultural Feasibility and Legal Feasibility have the smallest weights of 10
percent. Cultural Feasibility is how well the solution will be accepted into an
organization. Cultural Feasibility is not a significant issue because the main
executives of the company created and run the majority of the organization. There
are not enough people for a significant resistance within the company. Legal
Feasibility looks at how well a solution can be implemented within existing legal
and/or contractual obligations. There are not any legal obligations that Shield Boards
has in the foreseeable future, and the patent is currently being processed for the
product.
Technical Feasibility analyzes the practicality of the solution and the
availability of technical resources and expertise. It has a 15 percent weight for
analyzing the candidate solutions. The main executives have availability to the
needed technical resources and also have some of the technical skills needed.
Schedule Feasibility determines the reasonability of the project timetable and
has a 20 percent weight. The date that production goes live is quickly approaching, so
finding a system that can be implemented as quickly as possible is critical. Having the
system ready at a synonymous time with production carries a heavy weight for Shield
Boards. Waiting until after production begins will lead to more challenges during the
transition.
Economic Feasibility measures the cost-effectiveness of the solution. It has the
greatest significance, 30 percent, when weighting the candidate solutions. Capital is
33
vital to the success of any company. With a startup, costs are high, and money is
already a scare resource. The solution that is chosen must yield a good return for
what it costs because Shield Boards has limited funds. If Shield Boards invests in a
system, it must help the company grow in the long term, otherwise the company may
never recover from the loss.
Physical DFD
34
Input and Output Design
Input Screens:
Shopify dashboard system for administrators with overview of sales, visitors, payout
and activities. The information found in this system will be imported into the new VB
and SQL system.
35
List of orders placed:
List of customers:
List of products:
36
List of possible reports:
37
Our new system entails a Visual Basic CRM form that allows users to add and find
customer records, process customer orders, and email customer receipts and
shipping confirmation. The customer information will be input on the left and any
text output will be displayed on the right.
38
Output Screen:
SQL Server output with datastore information relating to customer information,
pledge information, order information, shipping information, and report information.
SQL will be used in our new system to generate reports and output customer data.
39
Order confirmation emailed to customer:
Shipping confirmation emailed to customer:
40
Implementation Plan
The goal of our implementation phase is to achieve a working customer
relationship management (CRM) system that meets the needs of Shield Boards, which
includes the transfer of data from the Kickstarter system to the new system, the
collection of new customer data, and the aggregation of data to produce financial and
sales reports. The software is being developed in-house. This software is an upgrade
for Shield Boards and consists of more advanced functions. Our implementation plan
is based off of the recommended software solution for Shield Boards and the feedback
for Shield Board employees.
According to our recommendation, the CRM software, the financial reporting
software that is linked to the CRM software, and the website customers will access
will all be designed in house. This allows us to support the user required business
processes with a customized user interface as well as maintain control and security
over all sensitive information. The application will be written in VB.NET and the
database will be created in SQL. The CRM software will be able to run on an up-todate operating system and will be installed on Shield Board employees’ computers.
However, the CRM software is also accessible via Citrix XenApp and the web-based
Citrix client, which allows users to connect to the application from their own personal
computer or mobile device. Data will be stored using cloud computing technologies
through Citrix, which means there is no need for servers to store the data. There will
be functions in the software that input and output the data from the different logins.
We will provide Shield Board employees with their unique user login in order to
access the CRM software and all necessary information. As part of the construction
phase, we will conduct systems testing, aggregating simulated data to generate
financial reports and test the financial reporting system, which will prove that the
application programs, written separately, work as one complete system.
Our system acceptance test, as part of the delivery phase of our
implementation plan, will involve verification testing (Alpha Testing), which will test
the simulated data. After accessing the software through the Citrix login and testing
and aggregating simulated data, we will transfer the existing data from the existing
41
systems, which includes Kickstarter and our exported Excel spreadsheets; this data
will be imported into the databases located in the new software. Then, the rest of the
verification testing will occur, which includes conducting Beta Testing and Audit
Testing. The system will be run in a live environment using real data and will test the
system’s performance, the amount of information the system can manage, and the
backup and recovery of information. The Audit Testing will verify that there are no
errors and the software is ready to be used. After all data is imported and testing is
completed, we will provide training and documentation for Shield Board employees,
which are the individuals that are using the system. The number of employees is very
few and training will last at the most one week. Employees will also have the
opportunity to test the system to ensure there is no confusion or errors.
After data has been imported and testing and training have been completed,
we will use a parallel conversion and launch the new CRM software and website
while Shield Boards is still in pre-production. After ensuring that there are no errors
in the new software in the live environment, we will terminate the Kickstarter
system.
Lessons Learned
The opportunity to develop a system for Shield Boards has been a valuable
experience. The experience was new to not only our team, but also to the Shield
Boards’ company, being a fairly new startup. More importantly, we were able to learn
more about system design during this project. Some key things we learned about
include understanding project constraints and feasibility, scope creep, and factfinding. Our team encountered constraints in regards to technical feasibility and
schedule feasibility. Our team was well equipped to meet the business needs of the
project and could devise a sound plan as to the value we would be able to provide to
Shield Boards. At the same time, our team lacks the experience and skills of an
esteemed programmer to provide technical expertise to this project. There were a
few ideas and features we wanted to add to the system during our system design
phase, but the problem we ran into was that we lacked the deep technical knowledge
42
to further determine the implementation of this model. We then created suggestions
for Shield Boards to look into in order to hire a more experienced team in that area,
so that they could implement that capability in Shield Boards’ system. Our team also
ran into schedule feasibility issues during this semester long project. First, there is
the evident constraint to a length of the semester, and then within that time period all
of the members on our team are full-time students. This created a problem where we
were not always able to give the Shield Boards team the desired attention throughout
the project. To combat this, we made sure to always work closely with Shield Boards
so they were always a part of the system design process with us.
We encountered scope creep during our project and were able to see how
scope creep takes place in reality. Our team has primarily learned about scope creep
in class. Our team was able to identify when the task of the project began falling
outside of the scope of our project goals. One instance is when we started designing
the payment process and how it should work; shortly into this task we found
ourselves diving more into how well we can create the output of reports to be
processed and given to an external party for review. Early identification of scope
creep allowed us to regain focus on the key objectives.
Fact-finding was another aspect of this project we were able to gain a lot of
value from. The techniques we used were being executed by the way we have learned
in the classroom. Throughout our project we were able to actually see how important
fact-finding is and the different kind of issues that we can encounter. For example,
when taking sampling documents, not being able to locate an earlier internal
document from the client can create a setback in where we have to work around not
knowing what data that document possessed. At the end of this project we were
effectively able to learn about system design, while also providing value to our client.
43