The root cause of many of the problems nonprofit organizations experience with their databases is often nothing to do with the software itself. Without plans to design and use them, processes to guide them, and people to effectively use and manage them, databases cannot deliver the value your organization wants or needs. Last month, we explored three plans that are essential for designing and using a database effectively. Today, we are looking at processes.
What’s a Process Got to Do with It?
First, let me explain what I mean when I say “process.” A business process is a collection of interrelated and sequenced tasks that result in the creation of a product, the delivery of service, or the achievement of a goal. Processes have defined starting and ending points and defined outputs. Some common examples of nonprofit processes include client intake, grant-writing, funder invoicing, hiring, onboarding, etc.
The flow of service delivery – how a client journeys through your program – can be considered one long process. The series of steps a staff member needs to complete to enroll or discharge a participant is also a process.
Why am I talking about processes in a post about databases? Because well-designed databases should follow and support your everyday workflows. The way in which your staff navigate through fields and screens should follow the flow of their work, so they can efficiently and logically document their work as they do it. If your database is designed to capture data in a flow that matches your team’s real-time workflow, you increase the odds of data being entered correctly, completely, and regularly.
When your process is unclear, illogical, or inconsistently followed and/or when your database is out of step with your processes, database users complain about “too many clicks” and “too many steps.” They forget or skip steps, leave fields blank, and don’t update data as they ought to – because the system doesn’t reflect their real world work.
Know Before You Go
Before you design or modify your database, know your processes. And then improve them.
What are they? Using your Logic Model as a guide, clarify and document the specific service delivery and administrative workflows that support your key activities. Focus on what data are collected at which points in the process.
How well do they work? Before you build a database to mirror your existing workflows, make sure they work! No use codifying ineffective practices. Find the most logical, efficient, and manageable processes that staff are likely to adopt and sustain. Consolidate steps whenever you can so that data that are collected at the same time or by the same person are entered in your system in a cohesive way.
How consistently are they implemented? Even if you have a sound process, if people aren’t following it, their experience of the database will be frustrating. Find out who isn’t following the process, when and why. Then make adjustments so you can reach consistent implementation.
Finally, document your processes! Create procedures or maps that outline the steps in your key workflows. This can be a blueprint for your database manager and a key tool in training staff.
The Bottom Line
If your processes don’t work, your database won’t either. Build clear, consistent processes and then design a database that will mirror (as closely as possible) those workflows and perhaps even guide or automate them!