Chapter 5. Planning Your QuickBase Solution

QuickBase is flexible enough to match the way you work. After all, you don’t want to change the way you do things to fit some programmer’s idea of how to organize your data. But that also means that, in order to get the most out of QuickBase, you need to have a clear picture of what you’re trying to accomplish.

So before you jump in and start creating tables and applications, take some time to define the problem you want QuickBase’s help with: Analyze your organization’s workflow (the steps you and your colleagues follow while doing your collective job), decide what kinds of information you need to track, and determine who needs to know what to keep things running smoothly. Defining and refining your problem now saves time down the road.

Defining the Problem

If you don’t understand a problem, you can’t solve it. So start by defining the problem you want to solve. Try writing it down as a broad statement—something like, “Having too many different versions of the budget is driving everyone nuts!” or “Sales reps in the field don’t have access to the most recent promotions,” or “Client requests keep getting lost; clients getting angry.” Maybe your whole team’s drowning in too much information and you want a better way to distribute information efficiently. Whatever the problem, you can solve it only if you identify the specifics.

Clarifying Your Problem

To clarify your problem, it helps to ask yourself questions like the ones below. As an example, imagine you’re a human resources (HR) manager for a big company and you need to track mountains of hiring requests and candidate résumés. Here are the kinds of questions you may start asking:

  • What’s the problem? It’s hard to coordinate the hiring needs of different offices around the country. Documents, like interview notes and résumés, get misplaced or attached to the wrong file. Promising candidates with specialized skills sometimes get overlooked and then are snatched up by another company. So my department’s problem is organizing and coordinating information that’s stored in a number of different locations.

  • Is it my problem or someone else’s? If it’s a shared problem, what part of it is mine? Because I’m the HR manager, it’s my problem. But my problem can also create problems for other hiring managers throughout the company. Solving this problem can save time for my fellow managers and maybe even result in better hiring decisions.

  • Is it a new problem or an old one? If it’s an old problem, how have we tried to solve it? What’s wrong with the old solution? Recent, fast growth has made this a new problem. Old methods for tracking applicants no longer work because the company now has offices across the nation.

  • What do I want to accomplish in solving the problem? I want to match up good candidates with job openings as quickly and efficiently as possible. I want to make it easy to find information about candidates—for instance, searching a candidate’s résumé for specific information (like level of education) or filtering candidates by specific criteria (like years of experience). I want to keep all our regional offices informed and coordinated. I also want to be able to share appropriate information easily. For example, candidates should be able to chart the progress of their application, hiring managers should be able to read all the details about a candidate, and clerical staff should be able to easily update everything.

  • How will I know that the problem has been solved? In other words, what conditions must the solution satisfy? When a hiring requisition’s approved, managers will automatically get a list of prioritized, qualified candidates. All data and documents related to the hiring process will be easy to find in a central, accessible location. Separate offices will all have access to the same candidate pool.

Again, putting it all in writing before you start to work in QuickBase is a big help. And it doesn’t have to look like a list of questions and answers. You could get a whole task force to brainstorm on a whiteboard, use an email list to gather ideas, or scribble away in a dimly lit café with a pencil stump if that’s more your style. You can even use mind-mapping software (these are programs that help you capture and organize bursts of related ideas; search Google for a list of popular options). The point is to think through your problem thoroughly and have all your thoughts, ideas, and concerns in one place.

The whole point of defining your problem is to clarify your objectives—the end results you want your solution to accomplish.

Identifying Your Objectives

Exploring a problem helps you clarify your objectives. For example, the HR manager from the previous example might come up with this list of objectives:

  • Centralize information so it’s easy to find.

  • Coordinate offices around the country.

  • Create different ways of viewing positions and candidates, based on the viewer’s role.

  • Automate such tasks as sending managers a list of qualified candidates when a position is approved.

To show you how to evaluate the challenges that your team faces, the rest of this chapter walks you through two different kinds of problems faced by two different kinds of companies.

Exploring Your Workflow

To see what problems QuickBase can help you solve, try breaking down your organization’s workflow into the steps that represent a typical day of doing business. When you distill a large or complex process into a series of steps, you can identify bottlenecks to get rid of, events to automate, and information to record. QuickBase can track every step of the process. It can even let the various players know when it’s their turn to step up and do their thing to move the work along.

A Typical Day in the Life of a Task

To get a sense of your organization’s workflow, think about a typical workday. Take a look at what sort of information comes in, who receives it, who gets it next, and what they do with it. Figure out all the steps that lead to the final outcome.

Example 1: Distribution company

Say you work for a distribution company that specializes in novelties, from squirting lapel flowers and dribble glasses to rubber chickens and whoopee cushions. When a new joke shop places a big order, a cascade of events follows from the time the order comes in to the time your delivery driver unloads the boxes.

A customer calls in and places an order with a customer service rep (CSR). The CSR passes the order on to Madge, fulfillment specialist extraordinaire, who pulls items from their shelves: a case of exploding cigars, a couple dozen bald head wigs in assorted skin tones, some of that new super-realistic fake vomit. Madge puts the items in boxes, along with a packing slip. When the order’s all packed, Madge tells Ron, the dispatcher, that the order’s ready to go. Ron assigns the order to a driver, and the driver loads the boxes into his truck and delivers them.

Figure 5-1 sketches out this workflow: An order passes through the hands of a CSR, a fulfillment specialist, a dispatcher, and a driver, who delivers everything to the customer. Each person in the chain has to do his or her job before the process can continue, and so each person needs notification before taking that next step.

When an order comes in to a distribution company, it travels through a clear chain of steps. A series of people each do a specific job, and then pass the order on to the next person in the chain. Start with a simple workflow; you can always add extra steps and alternative paths later on. Here, for example, customers may place an order over the Internet rather than talking to a sales rep, but these variations don’t change the flow once an order enters the system.
Figure 5-1. When an order comes in to a distribution company, it travels through a clear chain of steps. A series of people each do a specific job, and then pass the order on to the next person in the chain. Start with a simple workflow; you can always add extra steps and alternative paths later on. Here, for example, customers may place an order over the Internet rather than talking to a sales rep, but these variations don’t change the flow once an order enters the system.

Tip

When you lay out your own workflow, you can sketch it out on paper (stick figures optional), or use a computer program like Microsoft Visio or the open-source JBoss jBPM program (www.jboss.com).

Example 2: IT department

This time, imagine that you work in the IT department of a large corporation. Fellow employees who use the software you develop call you to report software bugs. When a new bug comes in, you enter it into a tracking system and assign it to one of the developers (Lauren, say), who’ll investigate and fix the problem. After Lauren has fixed the bug, Simon from Quality Assurance tests the fix to make sure everything’s working as it should. If the fix doesn’t work, then Simon sends it back to Lauren with a description of the problem. Lauren tries again and sends it back to Simon for more testing. When Simon gives the fix a green light, you can let the original caller know the bug’s been fixed.

Again, there’s a clear workflow here, as Figure 5-2 illustrates: You receive the bug and assign it to a developer (who fixes the problem) and a tester (who makes sure the fix works). The developer can’t fix a bug until you tell her about it, and the tester can’t test it until he gets the fix from the developer.

A workflow doesn’t always move sequentially from person #1 to person #2 to person #3; sometimes it branches. This workflow shows how the administrator assigns a bug to the developer (1), who then passes the bug fix back and forth with the QA tester until everything’s working (2). Finally, the QA tester reports back to the administrator (3).
Figure 5-2. A workflow doesn’t always move sequentially from person #1 to person #2 to person #3; sometimes it branches. This workflow shows how the administrator assigns a bug to the developer (1), who then passes the bug fix back and forth with the QA tester until everything’s working (2). Finally, the QA tester reports back to the administrator (3).

Note

Chapter 6 has other examples of business processes and problems, and shows you how to use QuickBase’s prebuilt applications to streamline and automate workflow.

Tracking Information

Of course there’s more to workflow than getting a package to a customer or tracking software fixes. Sometimes you need to track the status of different parts of your workflow. For example, when an order or job’s status changes, a problem comes up, or a deadline passes, you’ve got a new piece of information to deal with. QuickBase can capture and track all the information along your entire workflow (as well as for each individual player). So, first take a look at what information you need to track, and then break that information down by job role.

What Information Do You Need to Track?

Once you have a sense of the workflow, you can identify the information that comes into play (and changes) at each stage of the process. Think about the kinds of information that you need to track: things you already track routinely, things you wish somebody would keep track of, and information that lands between those two extremes.

Example 1: Distribution company

The novelty distribution company has a lot of information to track. For example:

  • What’s the customer’s account status?

  • Are any special promotions going on?

  • Are there enough items in stock to fill the order?

  • What items are in a package?

  • How many of each item are in a package?

  • Now that the order’s packed, how are inventory levels? Is it time to place an order with a supplier?

  • Where’s the package now?

  • When is the package scheduled to arrive at its destination?

As Figure 5-3 shows, the daily workflow generates information that goes into company records—and vice versa. For example, if Madge starts packing an order for three dozen rubber chickens, but there are only 27 in stock, what happens then? Or when a customer calls in demanding to know, “Where’s that carton of trick golf balls I ordered two weeks ago?” can the customer service rep find the answer quickly?

Each step in the process requires different information or raises different questions. Not all team members need the same information.
Figure 5-3. Each step in the process requires different information or raises different questions. Not all team members need the same information.

Above and beyond the daily information shuffle, most managers want to track data at a higher level, showing a bigger picture. They need information that answers questions like these:

  • What are our most popular items?

  • Which fulfillment specialists pack the most orders?

  • Which drivers deliver fastest?

  • Which promotions get the best customer response?

  • What are seasonal and regional buying patterns?

Finally, although the company needs to keep track of all this information somewhere, you don’t want to overwhelm team members with lots of data that has nothing to do with their jobs. Madge, for example, doesn’t know or care whether a customer’s account is in good standing or whether a box she packed yesterday is halfway to Kalamazoo or still on the loading dock. And Ron doesn’t care whether the shipment he’s assigning is a hot seller or a slow mover. So it’s a good idea to have a way to show individual team members only the info they need. The next section breaks down the general information the company tracks into the specific information that each team member needs to get the job done.

Example 2: IT department

The IT department also has lots of information to track, like:

  • Problem status: Unassigned, Open, In Development, On Hold, QA, Resolved.

  • Priority: Low, Medium, High, Flashing-Lights-and-Sirens.

  • Dependencies: Will fixing this bug affect other programs or functions?

  • Frequency: Is this a one-time problem or does it pop up all over the place?

  • Time: How long will it take to fix this bug?

  • Assigned to: Who’s dealing with it now? Also, which developers and testers are overloaded and which can handle another assignment?

In addition to this information regarding each individual bug, you’ll want to get a high-level overview, perhaps for a monthly or quarterly report. Just for starters, here are a few (you can probably come up with even more):

  • How many high-priority fixes do we deal with?

  • Which developers get the job done fastest (or, to flip it around, which developers work slowly and don’t meet deadlines)?

  • How long is IT taking, on average, to fix reported bugs?

  • How many open versus closed issues are there?

As in the distribution company example, not everyone needs all this info to do her job. Lauren the developer, for example, may not care which tester will check her fix. Simon, on the other hand, does need to know whose fix he’s testing, in case he needs to ask that developer a question. And even though a little healthy competition is a good thing, you don’t necessarily want Lauren eyeing the cubicle of another developer who’s been a little slow on the job lately. You’d prefer she focus on her own work quality instead of keeping tabs on her co-workers.

What Information Do People Need?

QuickBase lets you track tons of information. But the point is to give your team members only the information they need to do their jobs. You’re not helping anyone by swamping them with data they don’t need. And in some cases, you don’t want them poking their noses around in info that’s really none of their business.

Think about each player’s role in the workflow and what each person needs to know (or be able to look up) in order to move that process along.

Example 1: Distribution company

The workflow for the novelty distribution company is pretty straightforward. As the order passes from one team member to the next, it starts as information (an order), becomes actual goods, and then becomes information again (a completed order).

Here are the key players in the process, along with what each person needs to know:

  • Customer Service Rep. When someone calls to place an order, the CSR must have access to the customer’s account standing. (No whoopee cushions for you if your last invoice is six months past due.) Also, the CSR needs to know about any current promotions. For example, if there’s a promotion offering a free pair of fuzzy dice with every $100 order, then the CSR can use that information to increase sales. Because CSRs at this company also handle customer inquiries and complaints, each rep also needs to see information about order status and location.

  • Fulfillment specialists. Madge and her colleagues need to know which items are in an order. Fulfillment specialists also need to know where an order is going, so they can label the box. Finally, they need to know when an order has been packed, so you don’t get three different packers boxing up the same order three times.

  • Dispatcher. Ron needs to know when an order is ready to ship and where it’s going. He needs to know (or create) the drivers’ routes. Although Ron doesn’t necessarily care about the contents of a package, he needs to know its weight. If a driver runs into a problem en route that affects delivery schedules (a flat tire, for example), then Ron wants to know that, too.

  • Drivers. Drivers must know when a shipment’s ready to hit the road. They also need to know where they’re going, which packages get delivered where, and whether any packages require special handling. Special instructions are also helpful, like “Deliveries go to back door” or “Try to ignore vicious dog.” The driver completes the process by collecting the customer’s signature. When the driver submits that signature back to the organization, the process is complete, and the order is closed.

As you can see, each team member needs to know only a part of all the total information the company tracks. As you’ll see in the next section, QuickBase lets you restrict the information people can view depending on their role in the company. For example, fulfillment specialists might see open orders but not delivery schedules.

Example 2: IT department

In the IT example, the players needs to know when it’s their turn to go to work, and they need some info about the bugs they’re working on:

  • Administrator. This person, who’s in charge of assigning and tracking bugs, cares less about the specifics of any given problem than about its priority and status. The administrator is also responsible for making sure that bugs, once assigned, move through the pipeline in a timely manner. So she needs to know each bug’s status, who’s working on it and for how long, and which bugs are still unassigned (something the developer and tester don’t need to worry about yet).

  • Developer. To organize her workload, Lauren needs to know the nature of the problem, its priority, and the expected time frame for fixing it. She also wants to know the affected computer platform, the problem’s frequency, and any dependencies (that is, which system activities depend on other activities). If you’re changing the invoicing system, for example, then changes you make to that system may affect Accounts Receivable.

  • Tester. Over in QA, Simon needs to know when a fix is ready for testing. He wants to know which developer fixed the bug, in case he has questions. Dependencies are vital info for Simon, because if a fix affects other software or other parts of the same program, then he needs to test those, too. Priority and time frame are also important, because he can’t afford to let a high-priority issue sit there for a week awaiting testing.

Figure 5-4 shows how these pieces of information fit into the IT department’s workflow.

Although they’re all dealing with bugs, the people in this small IT department need different information at different times. The administrator needs to keep a high-level overview of the process, while the developer and the tester both focus on the nuts-and-bolts details of individual bugs.
Figure 5-4. Although they’re all dealing with bugs, the people in this small IT department need different information at different times. The administrator needs to keep a high-level overview of the process, while the developer and the tester both focus on the nuts-and-bolts details of individual bugs.

Keeping the Team on Track

Think of QuickBase as a virtual manager—or, perhaps, the best assistant manager you never had. It can tell team members when it’s time for them to do something, and it can let you know when the work’s been completed.

How Does Your Team Know What to Do and When?

Do people on your team waste time waiting for someone to tell them it’s their turn? Any dinky little spreadsheet can hold information, but QuickBase can let people know as soon as everything’s in place for them to get to work.

Example 1: Distribution company

Relying on people to pass on information can only slow down the workflow. If Madge has to walk over and tell Ron when a shipment’s ready to go, or if Ron has to print out a manifest and route for each driver and put it in an inbox, then problems are bound to pop up. If someone forgets to make a call or send an email, a customer’s important order can get delayed unnecessarily. Papers can get buried under other papers or slip down behind filing cabinets.

Here’s how QuickBase can help a distribution company stay on track:

  • Automatic notifications. When someone adds, modifies, or deletes part of an order, QuickBase can automatically send an email to the person who needs to know about it. You can even specify the kind of change that triggers an email: when a new order’s received, when the status of an order changes, when a shipment is assigned to a particular driver, and so on. Stay on Top of Things with Email Notifications tells you how to set up and fine tune automatic notifications.

  • Roles. In QuickBase, a role lets you control the level of access a person has in your application. You can set different roles for each job function, and then decide what information people in each role can see and what they can do with that information. For example, you may want the dispatcher to be able to see—but not change—the contents or destination of an order.

  • Reports. As Chapter 2 explains in detail, a report is a way to display an application’s data. You can sort, filter, and group the information any way you like, creating a report to display it. Reports are dynamic; that is, their content changes as the data changes. So, for example, you can create a report called Orders In Transit, which shows all orders with status fields that say “in transit.”

Here’s how these features would play out in the workflow: When a customer service rep creates a new order record, QuickBase adds it to the Open Tasks report for fulfillment specialists. Madge works her way down the list of open tasks, packing up orders. When an order’s packed, she changes its status from “processing” to “ready to ship.” That change in status triggers an email to Ron and adds the order to his My Open Tasks report. (You can even create a special report [Creating a Report from Scratch] called something like Unassigned Shipments, letting Ron focus on orders that are packed but not yet assigned to a driver.)

When Ron assigns the package to a driver and changes the order’s status to “in transit,” QuickBase adds the order to the driver’s manifest and fires off an email notification to the customer who placed the order, saying that the package is on its way. As the order works its way through the pipeline, you don’t have to worry about whether Madge gets sidetracked on the way to Ron’s desk, or whether Ron skips over a customer when he sends out a batch of notification emails.

Tip

You can even create a role for customers, so they can view what’s in their own order and see when it’ll be delivered.

Example 2: IT department

The IT example has similar opportunities for automating the workflow and passing along necessary information. Say you assign a bug to Lauren, the developer. When you make the assignment, QuickBase can send Lauren an email notification that she’s got a new problem to fix and add the bug to her My Open Issues report. You can even put the My Open Issues report on the developers’ Dashboard page (Creating Different Dashboard Pages for Different Roles), so it’s the first thing Lauren sees when she opens the Feature and Bug Tracker application, as shown in Figure 5-5.

When Lauren fixes the bug, she changes the status to “QA,” indicating that it’s time for the tester, Simon, to take a look. As application administrator, you can set things up so that Simon gets an automatic email notification that the fix is ready for him and has been added to his My Open Issues report. This way, you don’t have to send blizzards of emails to make sure that everyone knows what’s going on. Once you understand your process—and what QuickBase can do—you can use QuickBase to keep the work flowing right along.

When Lauren the developer opens the bug-tracking application, her Dashboard displays a report of all the open issues assigned to her, with their priority, status, and other information. To find out how to set up a custom Dashboard for different roles, see .
Figure 5-5. When Lauren the developer opens the bug-tracking application, her Dashboard displays a report of all the open issues assigned to her, with their priority, status, and other information. To find out how to set up a custom Dashboard for different roles, see Creating Different Dashboard Pages for Different Roles.

How Do You Know When the Work’s Done?

By defining your workflow and all the information it produces and modifies, you get a clear picture of what has to be in place so you know the work’s been done. In the distribution company example, a job begins when an order comes in and ends when the customer who placed the order gets the package. Also, each step in the process has a clear endpoint. The customer service rep’s job ends when the order is passed on to the fulfillment specialists; Madge’s job ends when she’s packed the order and changed its status; Ron’s job ends when he’s scheduled the package for delivery; and the driver’s job ends when the customer accepts delivery.

As the person in charge, you want to keep an eye on the workflow and make sure orders are flowing smoothly. But you may not need (or want) to be informed of every single status change. If you got an email every time Madge packed a box or every time Ron assigned a delivery, then your inbox would soon be flooded. It doesn’t hurt for you to have that information, but it’s overkill. So you can set up your QuickBase application to highlight what you need to know—in short, that people are getting their jobs done. For example, you may want a simple report at the end of the day showing completed vs. open orders.

Similarly, you can set up QuickBase to make sure an IT team is on track. To see who’s fixed which bugs, you can open the Bug Tracker application and view closed issues by type or by assigned person (both these reports are built into the application). To see who’s slacking, you can view open bugs by assigned person. And if your main concern is to make sure that your team addresses software problems quickly and efficiently, then you can subscribe to daily or weekly reports, showing important info like all high-priority bugs that remain unresolved.

From Planning to Application

With your objectives, workflow, and information in hand, you can create and tailor your QuickBase application to solve your specific problems and make your life oh so much easier.

Start from a Prebuilt Application

Start by looking at QuickBase’s prebuilt applications (A Tour of QuickBase’s Application Templates). You may find one that fits your situation perfectly. After all, Intuit created these applications after analyzing typical business problems and getting suggestions from QuickBase fans. Because QuickBase applications are so flexible, you can always customize them to better fit your needs. For example, you can edit prebuilt drop-down list items. (Maybe your IT department says a bug is in testing instead of saying QA.) You can even add a whole new table to a multi-table application. Chapter 6 explains all your choices.

Tip

You can also browse through QuickBase’s application library, which holds more than a hundred applications designed by QuickBase staff and customers alike. It’s a great place to find ideas about designing applications and using QuickBase to the max. To get there, start in My QuickBase, then click Create a New Application. Toward the bottom of the page, click the Visit the QuickBase Application Library link.

Design Your Own Application

On the other hand, you may prefer to build your application from the ground up. If you run a really unique small business, you may find it faster to start from scratch than try to adapt one of QuickBase’s built-in applications. Or maybe you’ve already been tracking data in a spreadsheet and just want to share it with your team via QuickBase. You can simply import what you’ve got rather than try to contort it into a prebuilt design. Chapter 7 is all about do-it-yourself applications. With the work you’ve done in this chapter—identifying the problem, objectives, workflow, and data to be tracked—you’ve got everything you need to create an application that gets the job done.

Consider the QuickBase Enterprise Edition

As you ponder your company’s workflow—especially if your organization is really big—you might realize that you’re going to need several corporate-level QuickBase accounts. But will those accounts get out of hand? How will you know what’s going on in all of them? And how can you be sure that company policies about security and access are followed across the board?

To address these concerns, consider purchasing the QuickBase Enterprise Edition (QuickBase Enterprise Edition), which lets you gather multiple accounts into one or more master account, or realm. As a realm administrator, you can monitor costs and usage statistics, set consistent password and access policies, control user access, and more. It’s a high-level administrative tool for organizations with complex needs. To find out more, go to www.quickbase.com, and then click Enterprise.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.119.14.235