Skip to Main Content

insightsarticles

Four questions to ask before purchasing an enterprise software system

08.31.23

We’ve all heard stories about organizations spending thousands on software projects, such as Enterprise Resource Planning (ERP), Electronic Health Record (EHR), or Student Information Systems (SIS) that take longer than expected to implement and exceed original budgets. One of the reasons this occurs is that organizations often don’t realize that purchasing a large, Commercial Off-The-Shelf (COTS) enterprise system is a significant undertaking. If the needs aren’t sufficiently defined, there can be many roadblocks, including implementation delays, increased cost, scope creep, and ultimately, unsatisfactory results (delayed or unfinished projects and cost overruns).

These systems are complex, and implementation efforts impact both internal and external stakeholders. Procurement often requires participation from different departments, each with unique goals and perspectives. Ignore these perspectives at your own peril. Here are key questions to consider for making the best buying decision:

  1. Should we purchase software that similar organizations have purchased?
    As vendor consolidation has diminished the number of distinct COTS systems available, this question is increasingly common. Following this approach is similar to deciding to buy the car that your neighbor did, because they seem satisfied. How can you be sure that the systems purchased by similar organizations will meet your needs, particularly if your needs are undefined? One way to identify your organization’s needs—and to avoid costly mistakes down the road—is to identify requirements during the procurement process.

  2. What are the functional and technical requirements of the system?Requirements are details that help describe a software system. There are two types of requirements and you need to understand and review both:

    Functional requirements. These define specific functions of a system to meet day-to-day needs of an organization or department. They describe the necessary system capabilities that allow users to perform their jobs. For example, “The vendor file must provide a minimum of four (4) remit-to addresses.” Functional requirements may also define the mandated state or federal capabilities required of a system, such as the ability to produce W-2 or 1099 forms.

    Technical requirements. These requirements identify criteria used to judge the operation of a system, rather than specific behaviors. They can be requirements that define what database the system must support. For example, “The system must support use of the client preferred database.” They may also describe security capabilities of the system, the ability to import or export data, or the ease of use and overall end-user interface.

  3. Who should help define and document requirements for the new enterprise system?

    When it comes to documenting and revising requirements, work with your IT staff; incorporating technology standards into a set of requirements is a best practice. Yet it is also necessary to seek input from non-IT individuals, or business process owners from multiple departments, those who will use and/or be affected by the new software system.

    Help these individuals or groups understand the capabilities of modern software systems by having them visit the sites of other organizations, or attend software industry conferences. You should also have them document the current system’s deficiencies. As for those in your organization who want to keep the current system, encourage their buy-in by asking them to highlight the system’s most valuable capabilities. Perspectives from both new system supporters and those not so eager to change will help build the best system.
     
  4. When do you revise enterprise system requirements?
    It is always important to begin the software procurement process with a documented set of requirements; you need them to identify the best solution. The same goes for the implementation process where vendors use the requirements to guide the setup and configuration of the new system. But be prepared to revise and enhance requirements when a vendor solution offers an improved capability or a better method to achieve the results. The best way to approach it is to plan to revise requirements constantly. This enables the software to better meet current needs, and often delivers enhanced capabilities.

Be sure to document system requirements for an efficient process

There may be thousands of requirements for an enterprise system. To make the procurement process as efficient as possible, continually define and refine requirements. While this takes time and resources, there are clear benefits:

  • Having requirements defined in an RFP helps vendors match the capabilities of their software systems to your organization’s needs and functional expectations. Without requirements, the software procurement and selection process has little framework, and from a vendor perspective becomes a subjective process — making it hard to get consistent information from all vendors.
  • Requirements help determine specific tasks and activities to address during the implementation process. While applications can’t always meet 100% of the requested functionalities, it’s important to emphasize the requirements that are most important to users, to help find the system that best meets the needs of your organization.
  • Requirements prove valuable even after implementation has begun, as they can help you test your system to make sure the software meets your organization’s particular needs before production use of the new system.

Our experienced consultants have led many software procurement projects and have firsthand knowledge about the challenges and opportunities associated with purchasing and implementing systems large and small. BerryDunn maintains an active database of requirements that we continually enhance, based on work performed for various clients and on technological advancements in the marketplace. Please contact us and we can help you define your requirements for large software system purchases.

Related Services

Consulting

Related Professionals

BerryDunn experts and consultants

There’s a good chance that your organization is in the position of needing to do more with less under the strain of staffing constraints and competing initiatives. With fewer resources to work with, you’ll need to be persuasive to get the green light on new enterprise technology initiatives. To do that, you need to present decision makers with well-thought-out and targeted business cases that show your initiative will have impact and will be successful. Yet developing such a business case is no walk in the park. Perhaps because our firm has its roots in New England, we sometimes compare this process to leading a hiking trip into the woods—into the wild. 

Just as in hiking, success in developing a business case for a new initiative boils down to planning, preparation, and applying a few key concepts we’ve learned from our travels. 

Consensus is critical when planning new technology initiatives

Before you can start the hike, everyone has to agree on some fundamentals: 

Who's going? 

Where are we going? 

When do we go and for how long? 

Getting everyone to agree requires clear communication and, yes, even a little salesmanship: “Trust me. The bears aren’t bad this time of year.” The same principle applies in proposing new technology initiatives; making sure everyone has bought into the basic framework of the initiative is critical to success.

Although many hiking trips involve groups of people similar in age, ability, and whereabouts, for your business initiative you need to communicate with diverse groups of colleagues at every level of the organization. Gaining consensus among people who bring a wide variety of skills and perspectives to the project can be complex.

To gain consensus, consider the intended audiences of your message and target the content to what will work for them. It should provide enough information for executive-level stakeholders to quickly understand the initiative and the path forward. It should give people responsible for implementation or who will provide specific skills substantive information to implement the plan. And remember: one of the most common reasons projects struggle to meet their stated objectives (and why some projects never materialize to begin with), is a lack of sponsorship and buy-in. The goal of a business case is to gain buy-in before project initiation, so your sponsors will actively support the project during implementation. 

Set clear goals for your enterprise technology project 

It’s refreshing to take the first steps, to feel that initial sense of freedom as you set off down the trail. Yet few people truly enjoy wandering around aimlessly in the wilderness for an extended period of time. Hikers need goals, like reaching a mountain peak or seeing famous landmarks, or hiking a predetermined number of miles per day. And having a trail guide is key in meeting those goals. 

For a new initiative, clearly define goals and objectives, as well as pain points your organization wishes to address. This is critical to ensuring that the project’s sponsors and implementation team are all on the same page. Identifying specific benefits of completing your initiative can help people keep their “eyes on the prize” when the project feels like an uphill climb.

Timelines provide additional detail and direction—and demonstrate to decision makers that you have considered multiple facets of the project, including any constraints, resource limitations, or scheduling conflicts. Identifying best practices to incorporate throughout the initiative enhances the value of a business case proposition, and positions the organization for success. By leveraging lessons learned on previous projects, and planning for and mitigating risk, the organization will begin to clear the path for a successful endeavor. 

Don’t compromise on the right equipment

Hiking can be an expensive, time-consuming hobby. While the quality of your equipment and the accuracy of your maps are crucial, you can do things with limited resources if you’re careful. Taking the time to research and purchase the right equipment, (like the right hiking boots), keeps your fun expedition from becoming a tortuous slog. 

Similarly, in developing a business case for a new initiative, you need to make sure that you identify the right resources in the right areas. We all live with resource constraints of one sort or another. The process of identifying resources, particularly for funding and staffing the project, will lead to fewer surprises down the path. As many government employees know all too well, it is better to be thorough in the budget planning process than to return to authorizing sources for additional funding while midstream in a project. 

Consider your possible outcomes

You cannot be too singularly focused in the wild; weather conditions change quickly, unexpected opportunities reveal themselves, and being able to adapt quickly is absolutely necessary in order for everyone to come home safely. Sometimes, you should take the trail less traveled, rest in the random lean-to that you and your group stumble upon, or go for a refreshing dip in a lake. By focusing on more than just one single objective, it often leads to more enjoyable, safe, and successful excursions.

This type of outlook is necessary to build a business case for a new initiative. You may need to step back during your initial planning and consider the full impact of the process, including on those outside your organization. For example, you may begin to identify ways in which the initiative could benefit both internal and external stakeholders, and plan to move forward in a slightly new direction. Let’s say you’re building a business case for a new land management and permitting software system. Take time to consider that this system may benefit citizens, contractors, and other organizations that interact with your department. This new perspective can help you strengthen your business case. 

Expect teamwork

A group that doesn’t practice teamwork won’t last long in the wild. In order to facilitate and promote teamwork, it’s important to recognize the skills and contributions of each and every person. Some have a better sense of direction, while some can more easily start campfires. And if you find yourself fortunate enough to be joined by a truly experienced hiker, make sure that you listen to what they have to say.

Doing the hard work to present a business case for a new initiative may feel like a solitary action at times, but it’s not. Most likely, there are other people in your organization who see the value in the initiative. Recognize and utilize their skills in your planning. We also suggest working with an experienced advisor who can leverage best practices and lessons learned from similar projects. Their experience will help you anticipate potential resistance and develop and articulate the mitigation strategies necessary to gain support for your initiative.

If you have thoughts, concerns, or questions, contact our team. We love to discuss the potential and pitfalls of new initiatives, and can help prepare you to head out into the wild. We’d love to hear any parallels with hiking and wilderness adventuring that you have as well. Let us know! 

BerryDunn’s local government consulting team has the experience to lead technology planning initiatives and develop actionable plans that help you think strategically and improve service delivery. We partner with you, maintaining flexibility and open lines of communication to help ensure that your team has the resources it needs.

Our team has broad and deep experience partnering with local government clients across the country to modernize technology-based business transformation projects and the decision-making and planning efforts. Our expertise includes software system assessments/planning/procurement and implementation project management; operational, management, and staffing assessments; information security; cost allocation studies; and data management.  

Article
Into the wild: Building a business case for a new enterprise technology project

Read this if your organization is planning on upgrading or replacing an enterprise technology system.

It can be challenging and stressful to plan for technology initiatives, especially those that involve and impact every area of your organization. Common initiatives include software upgrades or replacements for:

  • Financial management, such as Enterprise Resource Planning (ERP) systems
  • Asset management systems
  • Electronic health records (EHR) systems
  • Permitting and inspections systems

Though the number of considerations when planning enterprise technology projects can be daunting, the greatest mistake you can make is not planning at all. By addressing just a few key areas, you can avoid some of the most common pitfalls, such as exceeding budget and schedule targets, experiencing scope creep, and losing buy-in among stakeholders. Here are some tips to help you navigate your next project:

Identify your IT project roles and resources

While most organizations understand the importance of identifying project stakeholder groups, it is often an afterthought. Defining these roles at the outset of your project helps you accurately estimate the work effort.

Your stakeholder groups may include:

  • An executive sponsor
  • A steering committee
  • A project manager
  • Functional leads
  • A technical team

Once you’ve established the necessary roles, you can begin reviewing your organization’s resources to determine the people who will be available to fill them. Planning for resource availability will help you avoid delays, minimize impact to regular business processes, and reduce the likelihood of burnout. But this plan won’t remain static—you can expect to make updates throughout the project.

Establish clear goals and objectives to keep your technology project on track

It’s important that an enterprise technology project has established goals and objectives statements. These statements will help inform decision-making, provide benchmarks for progress, and measure your project’s success. They can then be referenced when key stakeholders have differing perspectives on the direction to take with a pending decision. For example, if the objective of your project is to reduce paper-based processes, you may plan for additional computer workstations and focus technical resources on provisioning them. You’ll also be able to measure your success in the reduction of paper-based tasks.

Estimate your IT project budget accurately

Project funding is hardly ever overlooked, but can be complex with project budgets that are either underestimated or estimated without sufficient rationale to withstand approval processes and subsequent budget analysis. You may find that breaking down estimates to a lower level of detail helps address these challenges. Most technology projects incur costs in three key areas:

  • Vendor cost: This could include both one-time software implementation costs as well as recurring costs for maintenance and ongoing support.
  • Infrastructure cost: Consider the cost of any investments needed to support your project, such as data center hardware, networking components, or computing devices.
  • Supplemental resource cost: Don’t forget to include the cost of any additional resources needed for their specialized knowledge or to simply backfill project staff. This could include contracted resources or the additional cost of existing resources (i.e., overtime).

A good technology project budget also includes a contingency amount. This amount will depend on your organization’s standards, the relative level of confidence in your estimates, and the relative risk.

Anticipate the need for change management

Depending on the project, staff in many areas of your organization will be impacted by some level of change during a technology implementation. External stakeholders, such as vendors and the public, may also be affected. You can effectively manage this change by proactively identifying areas of likely change resistance and creating strategies to address them.

In any technology implementation, you will encounter change resistance you did not predict. Having strategies in place will help you react quickly and effectively. Some proven change management strategies include communicating throughout your project, involving stakeholders to get their buy-in, and helping ensure management has the right amount of information to share with their employees.

Maintain focus and stay flexible as you manage your IT project

Even with the most thought-out planning, unforeseen events and external factors may impact your technology project. Establish mechanisms to regularly and proactively monitor project status so that you can address material risks and issues before their impact to the project grows. Reacting to these items as they arise requires key project stakeholders to be flexible. Key stakeholders must recognize that new information does not necessarily mean previous decisions were made in error, and that it is better to adapt than to stick to the initial direction.

Whether you’re implementing an ERP, an EHR, or enterprise human resources or asset management systems, any enterprise technology project is a massive undertaking, involving significant investment and a coordinated effort with individuals across multiple areas of an organization. Common mistakes can be costly, but having a structured approach to your planning can help avoid pitfalls. Our experienced, objective advisors have worked with public and private organizations across the country to oversee large enterprise projects from inception to successful completion.

Contact our software consulting team with any questions.

Article
Planning for a successful enterprise technology project

Read this if you are a State Medicaid Director, State Medicaid Chief Information Officer, State Medicaid Project Manager, or State Procurement Officer—or if you work on a State Medicaid Enterprise System (MES) certification effort.

On October 24, 2019, the Centers for Medicaid and Medicare Services (CMS) published the Outcomes-Based Certification (OBC) guidance for the Electronic Visit Verification (EVV) module. Now, CMS is looking to bring the OBC process to the rest of the Medicaid Enterprise. 

The shift from a technical-focused certification to a business outcome-focused approach presents a unique opportunity for states as they begin re-procuring—and certifying—their Medicaid Enterprise Systems (MES).

Once you have defined the scope of your MES project—and know you need to undertake CMS certification—you need to ask “what’s next?” OBC can be a more efficient certification process to secure Federal Financial Participation (FFP).

What does OBC certification entail?

Rethinking certification in terms of business outcomes will require agencies to engage business and operations units at the earliest possible point of the project development process to define the program goals and define what a successful implementation is. One way to achieve this is to consider MES projects in three steps. 

Three steps to OBC evaluation

Step 1: Define outcomes

The first step in OBC planning seems easy enough: define outcomes. But what is an outcome? To answer that, it’s important to understand what an outcome isn’t. An outcome isn’t an activity. Instead, an outcome is the result of the activity. For example, the activity could be procuring an EVV solution. In this instance, an outcome could be that the state has increased the ability to detect fraud, waste, and abuse through increased visibility into the EVV solution.

Step 2: Determine measurements

The second step in the OBC process is to determine what to measure and how exactly you will measure it. Deciding what metrics will accurately capture progress toward the new outcomes may be intuitive and therefore easy to define. For example, a measure might simply be that each visit is captured within the EVV solution.

Increasing the ability to detect fraud, waste, and abuse could simply be measured by the number of cases referred to a Medicaid fraud unit or dollars recovered. However, you may not be able to easily measure that in the short-term. Instead, you may need to determine its measurement in terms of an intermediate goal, like increasing the number of claims checked against new data as a result of the new EVV solution. By increasing the number of checked claims, states can ensure that claims are not being paid for unverified visits. 

Step 3: Frequency and reporting

Finally, the state will need to determine how often to report to measure success. States will need to consider the nuances of their own Medicaid programs and how those nuances fit into CMS’ expectations, including what data is available at what intervals.

OBC represents a fundamental change to the certification process, but it’s important to highlight that OBC isn’t completely unfamiliar territory. There is likely to be some carry-over from the certification process as described in the Medicaid Enterprise Certification Toolkit (MECT) version 2.3. The current Medicaid Enterprise Certification (MEC) checklists serve as the foundation for a more abbreviated set of criteria. New evaluation criteria will look and feel like the criteria of old but are likely to be a fraction of the 741 criteria present in the MECT version 2.3.

OBC offers several benefits to states as you navigate federal certification requirements:

  1. You will experience a reduction in the amount of time, effort, and resources necessary to undertake the certification process. 
  2. OBC refocuses procurement in terms of enhancements to the program, not in new functions. Consequently, states will also be able to demonstrate the benefits that each module brings to the program which can be integral to stakeholder support of each module. 
  3. Early adoption of the OBC process can allow you to play a more proactive role in certification efforts.

Continue to check back for a series of our project case studies. Additionally, if you are considering an OBC effort and have questions, please contact our team. You can read the OBC guidance on the CMS website here
 

Article
Three steps to outcomes-based certification

Editor's note: read this blog if you are a state liquor administrator or at the C-level in state government. 

Surprisingly, the keynote address to this year’s annual meeting of the National Alcohol Beverage Control Association (NABCA) featured few comments on, well, alcohol. 

Why? Because cannabis is now the hot topic in state government, as consumers await its legalization. While the thought of selling cannabis may seem foreign to some state administrators, many liquor agencies are―and should be―watching. The fact is, state liquor agencies are already equipped with expertise and the technology infrastructure needed to lawfully sell a controlled substance. This puts them in a unique position to benefit from the industry’s continued growth. Common technology includes enterprise resource planning (ERP) and point-of-sale (POS) systems.

ERP

State liquor agencies typically use an ERP system to integrate core business functions, including finance, human resources, and supply chain management. Whether the system is handling bottles of wine, cases of spirits, or bags of cannabis, it is capable of achieving the same business goals. 

The existing checks and balances on controlled substances like alcohol in their current ERP system translate well to cannabis products. This leads to an important point: state governments do not need to procure a new IT system solely for regulating cannabis.

By leveraging existing ERP systems, state liquor agencies can sidestep much of the time, effort, and expense of selecting, procuring, and implementing a new system solely for cannabis sales and management. In control states, where the state has exclusively control of alcohol sales, liquor agencies are often involved in every stage of product lifecycle, from procurement to distribution to retailing.

With a few modifications, the spectrum of business functions that control states require for liquor—procuring new product, communicating with vendors and brokers, tracking inventory, and analyzing sales—can work just as well for cannabis.

POS

POS systems are necessary for most retail stores. If a state liquor agency decides to sell cannabis products in stores, they can use a POS system to integrate with the agency’s ERP system, though store personnel may require training to help ensure compliance with related regulations.

Cannabis is cash only (for now)

There is one major difference in conducting liquor versus cannabis sales at any level: currently states conduct all cannabis sales in cash. With cannabis illegal on the federal level, major banks have opted to decline any deposit of funds earned from cannabis-related sales. While some community banks are conducting cannabis-related banking, many retailers selling recreational cannabis in places like Colorado and California still deal in cash. While risky and not without challenges, these transactions are possible and less onerous to federal regulators. 

Taxes 

As markets develop, monthly tax revenue collections from cannabis continue to grow. Colorado and California have found cannabis-related tax revenue a powerful tool in hedging against uncertainty in year-over-year cash flows. Similar to beer sold wholesale, which liquor agencies tax even in control states, cannabis can be taxed at multiple levels depending on the state’s business model.

E-commerce

Even with liquor, few state agencies have adopted direct-to-consumer online sales. However, as other industries continue shifting toward e-commerce and away from brick and mortar retailing, private sector competition will likely feed increased consumer demand for online sales. Similar to ERP and POS systems, states can increase revenue by selling cannabis through e-commerce sales channels. In today’s online retail world, many prefer to buy products from their computer or smart phone instead of shopping in stores. State agencies should consider selling cannabis via the web to maximize this revenue opportunity. 

Applying expertise in the systems and processes of alcoholic beverage control can translate into the sale and regulation of cannabis, easing the transition states face to this burgeoning industry. If your agency is considering bringing in cannabis under management, you should consider strategic planning sessions and even begin a change management approach to ensure your agency adapts successfully. 

Article
Considering cannabis: How state liquor agencies can manage the growing industry

Editor’s note: If you are a higher education CFO, CIO, CTO or other C-suite leader, this blog is for you.

The Gramm-Leach-Bliley Act (GLBA) has been in the news recently as the Federal Trade Commission (FTC) has agreed to extend a deadline for public comment regarding proposed changes to the Safeguards Rule. Here’s what you need to know.

GLBA, also known as the Financial Modernization Act, is a 1999 federal law providing rules to financial institutions for protecting consumer information. Colleges and universities fall under this act because they conduct financial activities (e.g., administration of financial aid, loans, and other financial services).

Under the Safeguards Rule financial Institutions must develop, implement, and maintain a comprehensive information security program that consists of safeguards to handle customer information.

Proposed changes

The FTC is proposing five modifications to the Safeguards Rule. The new act will:

  • Provide more detailed guidance to impacted institutions regarding how to develop and implement specific aspects of an overall information security program.
  • Improve the accountability of an institution’s information security programs.
  • Exempt small business from certain requirements.
  • Expand the definition of “financial institutions” to include entities engaged in activities that the Federal Reserve Board determines to be incidental to financial activities.
  • Propose to include the definition of “financial institutions” and related examples in the rule itself rather than cross-reference them from a related FTC rule (Privacy of Consumer Financial Information Rule).

Potential impacts for your institution

The Federal Register, Volume 84, Number 65, published the notice of proposed changes that once approved by the FTC would add more prescriptive rules that could have significant impact on your institution. For example, these rules would require institutions to:

  1. Expand existing security programs with additional resources.
  2. Produce additional documentation.
  3. Create and implement additional policies and procedures.
  4. Offer various forms of training and education for security personnel.

The proposed rules could require institutions to increase their commitment in time and staffing, and may create hardships for institutions with limited or challenging resources.

Prepare now

While these changes are not final and the FTC is requesting public comment, here are some things you can do to prepare for these potential changes:

  • Evaluate whether your institution is compliant to the current Safeguards Rule.
  • Identify gaps between current status and proposed changes.
  • Perform a risk assessment.
  • Ensure there is an employee designated to lead the information security program.
  • Monitor the FTC site for final Safeguard Rules updates.

In the meantime, reach out to us if you would like to discuss the impact GLBA will have on your institution or if you would like assistance with any of the recommendations above. You can view a comprehensive list of potential changes here.

Source: Federal Trade Commission. Safeguards Rule. Federal Register, Vol. 84, No. 65. FTC.gov. April 4, 2019. https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/safeguards-rule

Article
Higher ed: GLBA is the new four-letter word, but it's not as bad as you think

Focus on the people: How higher ed institutions can successfully make an ERP system change

The enterprise resource planning (ERP) system is the heart of an institution’s business, maintaining all aspects of day-to-day operations, from student registration to staff payroll. Many institutions have used the same ERP systems for decades and face challenges to meet the changing demands of staff and students. As new ERP vendors enter the marketplace with new features and functionality, institutions are considering a change. Some things to consider:

  1. Don’t just focus on the technology and make change management an afterthought. Transitioning to a new ERP system takes considerable effort, and has the potential to go horribly wrong if sponsorship, good planning, and communication channels are not in place. The new technology is the easy part of a transition—the primary challenge is often rooted in people’s natural resistance to change.  
  2. Overcoming resistance to change requires a thoughtful and intentional approach that focuses on change at the individual level. Understanding this helps leadership focus their attention and energy to best raise awareness and desire for the change.
  3. One effective tool that provides a good framework for successful change is the Prosci ADKAR® model. This framework has five distinct phases that align with ERP change:

These phases provide an approach for developing activities for change management, preparing leadership to lead and sponsor change and supporting employees through the implementation of the change.

The three essential steps to leveraging this framework:

  1. Perform a baseline assessment to establish an understanding of how ready the organization is for an ERP change
  2. Provide sponsorship, training, and communication to drive employee adoption
  3. Prepare and support activities to implement, celebrate, and sustain participation throughout the ERP transition

Following this approach with a change management framework such as the Prosci ADKAR® model can help an organization prepare, guide, and adopt ERP change more easily and successfully. 

If you’re considering a change, but need to prepare your institution for a healthy ERP transition using change management, chart yourself on this ADKAR framework—what is your organization’s change readiness? Do you have appropriate buy-in? What problems will you face?

You now know that this framework can help your changes stick, and have an idea of where you might face resistance. We’re certified Prosci ADKAR® practitioners and have experience guiding Higher Ed leaders like you through these steps. Get in touch—we’re happy to help and have the experience and training to back it up. Please contact the team with any questions you may have.

1Prosci ADKAR®from http://www.prosci.com

Article
Perspectives of an Ex-CIO

Law enforcement, courts, prosecutors, and corrections personnel provide many complex, seemingly limitless services. Seemingly is the key word here, for in reality these personnel provide a set number of incredibly important services.

Therefore, it should surprise no one that justice and public safety (J&PS) IT departments should also provide a well-defined set of services. However, these departments are often viewed as parking lots for all technical problems. The disconnect between IT and other J&PS business units often stems from differences in organizational culture and structure, and differing department objectives and goals. As a result, J&PS organizations often experience misperception between business units and IT. The solution to this disconnect and misperception? Defining IT department services.

The benefits of defined IT services

  1. Increased business customer satisfaction. Once IT services align with customer needs, and expectations are established (e.g., service costs and service level agreements), customers can expect to receive the services they agreed to, and the IT department can align staff and skill levels to successfully meet those needs.
  2. Improved IT personnel morale. With clear definition of the services they provide to their customers, including clearly defined processes for customers to request those services, IT personnel will no longer be subject to “rogue” questions or requests, and customers won’t be inclined to circumvent the process. This decreases IT staff stress and enables them to focus on their roles in providing the defined services. 
  3. Better alignment of IT services to organizational needs. Through collaboration between the business and IT organizations, the business is able to clearly articulate the IT services that are, and aren’t, required. IT can help define realistic service levels and associated services costs, and can align IT staff and skills to the agreed-upon services. This results in increased IT effectiveness and reduced confusion regarding what services the business can expect from IT.
  4. More collaboration between IT and the organization. The collaboration between the IT and business units in defining services results in an enhanced relationship between these organizations, increasing trust and clarifying expectations. This collaborative model continues as the services required by the business evolve, and IT evolves to support them.
  5. Reduced costs. J&PS organizations that fail to strategically align IT and business strategy face increasing financial costs, as the organization is unable to invest IT dollars wisely. When a business doesn’t see IT as an enabler of business strategy, IT is no longer the provider of choice—and ultimately risks IT services being outsourced to a third-party vendor.

Next steps
Once a J&PS IT department defines its services to support business needs, it then can align the IT staffing model (i.e., numbers of staff, skill sets, roles and responsibilities), and continue to collaborate with the business to identify evolving services, as well as remove services that are no longer relevant. Contact us for help with this next step and other IT strategies and tactics for justice and public safety organizations.

Article
The definition of success: J&PS IT departments must define services

While new software applications help you speed up processes and operations, deciding which ones will work best for your organization can quickly evolve into analysis paralysis, as there are so many considerations.

Case in point: Software as a Service (SaaS) model
The benefits of the SaaS model, in which a vendor remotely hosts an organization’s applications, are fairly well known: your organization doesn’t have to shell out for costly hardware, the vendor tackles upgrades, backups, data recovery, and security, and you have more time and money to focus on your business goals.

There are multiple factors to look at when determining whether a SaaS solution is right for you. We’ve compiled a list of the top three SaaS considerations:

1. Infrastructure and capacity
Your organization should consider your own people, processes, and tools when determining whether SaaS makes sense. While an on-site solution may require purchasing new technologies, hiring new staff, and realigning current roles and responsibilities to maintain the system, maintaining a SaaS solution may also require infrastructure updates, such as increased bandwidth to sufficiently connect to the vendor's hosting site.

Needless to say, it’s one thing to maintain a solution; it’s an entirely different thing to keep it secure. An on-site hosting solution requires constant security upgrades, internal audits, and a backup system—all of which takes time and money. A SaaS model requires trust in your vendor to provide security. Make sure your potential vendor uses the latest security measures and standards to keep your critical business data safe and secure.

2. Expense
When you purchase major assets—for example, hardware to host its applications—it incurs capital expenses. Conversely, when you spend money on day-to-day operations (SaaS subscriptions), it incurs operating expenses.

You should weigh the pros and cons of each type of expense when considering a SaaS model. On-site upfront capital expenses for hosting hardware are generally high, and expenses can spike overtime when you update the technology, which can be difficult to predict. And don’t forget about ongoing costs for maintenance, software upgrades, and security patches.

In the SaaS model, you spread out operating costs over time and can predict costs because you are paying via subscription—which generally includes costs for maintenance, software upgrades, and security patches. However, remember you can depreciate capital expenses over time, whereas the deductibility of operating expenses are generally for the year you use them.

3. Vendor viability
Finally, you need to conduct due diligence and vet SaaS vendors before closing the deal. Because SaaS vendors assume the responsibility for vital processes, such as data recovery and security, you need to make sure the potential vendor is financially stable and has a sustainable business model. To help ensure you receive the best possible service, select a vendor considered a leader in its market sector. Prepare a viable exit strategy beforehand so you can migrate your business processes and data easily in case you have any issues with the SaaS provider.

You must read—and understand—the fine print. This is especially important when it comes to the vendor’s policies toward data ownership and future migrations to other service providers, should that become necessary. In other words: Make sure you have final say and control over your data.

Every organization has different aspects of their situation to consider when making a SaaS determination. Want to learn more? It’s a snap! Contact the authors: Clark Lathrum and Matthew Tremblay

Article
SaaS: Is it right for you? Making SaaS determinations a snap.