Citywide Operational Taxonomy _ Quantified Qu.docx

Citywide Operational Technology Taxonomy

Section 1: Introduction

1.1 Background:

The City of Atlanta believes digital transformation starts and ends with the customer and understands that customers no longer distinguish between how they conduct business in their personal lives from how they interact with City government. Transformation cannot be achieved without addressing how the city is structured and where the connections and disconnections exist, that enable or prevent a seamless customer experience.

The City of Atlanta is seeking proposals from qualified vendors to translate the City’s organizational strategies into a comprehensive enterprise architecture with future state conceptual architecture, roadmap, and taxonomy documentation services. The goal is to create an operational understanding of the full technological and functional business landscape, so strategic operational decision making is done with full awareness of potential impacts enterprise wide and to ensure interoperability and efficient data management toward digital transformation and a seamless citizen experience with government.

The overarching strategic goals for this effort are as follows:

· Establishment of a digital backbone that mirrors real-world operations.

· Improvement of the Customer Relationship Management (CRM) system, enabling faster and smarter service.

· Setting the foundation for our operational excellence journey and long-term operational agility.

1.2 Objectives:

In furtherance of the mayoral pillars for the City of Atlanta to be an Effective and Ethical government, Built for the Future, city leadership endeavors to be recognized with the Malcolm Baldrige National Quality Award. The foundation to that journey is decomposition of our current operational landscape, with the recently implemented Microsoft Dynamics CRM system at the core, and the development of an achievable future state and road map to world class operational efficiency, for all business functions, customer-facing services, and operational units. This taxonomy is the foundational enabler of the city’s performance excellence. This effort is designed to strengthen strategic coherence, operational effectiveness, and citizen-centric service delivery. With the core of the effort centering on the CRM, it is critical that the taxonomy maps operational business processes that touch the CRM, and clear logical routing is established and documented to inform 311 queue prioritization and classification, especially for citizen-facing services, ensuring that the taxonomy informs how services are structured and how residents experience those services.

1.3 Scope of Work:

The selected vendor will work with the City of Atlanta to create an enterprise technology and operational taxonomy that will capture the following information:

· Discovery and Assessment:

· An inventory of all technology software and applications, alongside review of all business functions, customer-facing services, and operational units engaged throughout the City of Atlanta.

· Listing of all departments that utilize inventoried technologies and where each function, service, and unit is operational. While the central point and function is based upon the CRM, the taxonomy shall cover all operational areas including those not connected to the CRM.

· Discovery should be multi-modal including interviews, and cross-department surveys.

· Reconciliation of discovered inventory should be reconciled with known inventory of record between IT and Procurement.

· Stakeholder Engagement:

· Identified point of contact, and application, or process owner for each department utilizing inventoried technologies, functions, and services.

· Facilitation of cross-departmental workshops to gather input and gain consensus where necessary

· Design and Modeling:

· Process and function mapping for all business functions, customer-facing services, and operational units

· Network and Server Topology for inventoried technologies

· Functionality of the technologies

· Redundancy in functionality of inventoried technologies

· Interoperability assessments

· Data Integration assessments

· Governance and Sustainability

· Annual cost of the technologies

· Technology Board process reviews and suggestions

· Information Security Standards Checklist

· Architecture Review Board (weekly Tuesdays)

· Change Advisory Board (weekly Wednesdays)

· Taxonomy management plan that ensures long-term scalability and adaptability

· CRM Optimization Plan based on taxonomic alignment to business functions and call center workflows

· Operational Optimization Plan based on taxonomic alignment to business functions and streamlined services, focused on eliminating redundancy and enhancing efficiency for processes and relationships that are not connected to the CRM.

The associated report must include recommendations for optimization, reducing total cost of ownership (TCO), strategic opportunities to expand existing functionality where applicable, and recommendations for streamlining citywide governance of technology investments, business functions, and customer-facing services.

Section 2: Vendor Qualifications

2.1 Vendor Eligibility:

Vendor must demonstrate capability of developing thorough, practical, and high-quality reports for complex business and service application and process relationships. The vendor must provide documentation regarding expertise, experience, and ability to perform the review of enterprise technology landscapes described within this Statement of Work. Prospective vendors must submit the following to demonstrate their qualifications:

· Vendor must provide at least 3 examples of prior reports related to enterprise systems mapping or analysis of application/process relationships.

· A narrative description (1–2 pages) outlining vendor’s relevant experience in reviewing enterprise operational and technology landscapes (must include at least 2 projects within the last 2-3 years last 5 years). Addressing scope, design, and maintenance plans, preferably with Microsoft Dynamics.

· A description of approach and tools used in landscape reviews (e.g., application portfolio management tools, configuration management databases, metadata repositories).

· Summary of methodologies and frameworks used (e.g., TOGAF, ITIL, TBM, or custom taxonomy models).

· Examples of previous artifacts (ex: file layouts, dataflow maps, architectural diagrams)

· Resumes for all proposed project staff including:

· Years of experience in enterprise architecture, taxonomy development, or system analysis (5 years minimum preferred)

· Specific roles played in relevant efforts

· Relevant certifications (e.g., TOGAF, ITIL, PMP, etc.)

2.2 References:

Vendor respondents must provide evidence of successful taxonomic, enterprise architecture efforts for previous projects/clients. Specific experience with interfaces regarding Customer Relationship Management systems is preferred. Previous experience with the development of integrations for governmental entities is preferred.

Section 3: Project Requirements

3.1 Solution Design:

Vendor must provide detailed documentation (including dataflow diagrams and file layouts), regarding the design and function of applications, functions, services and operational units. Upon project completion, the vendor must conduct technical presentations and walk-throughs for City of Atlanta support resources to explain the methodology, outcomes, and recommendations of the report.

3.2 Implementation Plan:

The vendor must provide a detailed plan explaining the approach for report development. The plan should include information regarding the tasks, milestones, and timeline for completion. The plan should include a listing of resources/roles that the vendor will assign to the project.

3.3 Training:

The vendor must provide detailed documentation regarding the design and function of the report. Upon project completion, the vendor must conduct technical presentations/walk-throughs for City of Atlanta support resources to explain the design/maintenance of the report.

3.4 Verification and Quality Assurance:

Vendor must collaborate with the City of Atlanta functional SMEs and technical resources to verify all applications and their functions for the entire environment. The verification will be conducted utilizing known relationships (e.g., Customer Relationship Management ecosystem).

Initial verification will be done in conjunction with project team resources – any issues encountered must be quickly resolved by the vendor.

Project team verification will be followed by User Acceptance Testing with relevant SMEs - any issues encountered must be quickly resolved by the vendor.

3.5 Change Management:

The City of Atlanta requires a three-step process regarding change management for applications/systems.

1. Before installation of new systems/applications, the City of Atlanta requires approval by the IT Architectural Board (ARB). Vendors must provide two documents before ARB approval:

a. Information Systems Standards Checklist: The ISS Checklist is a form (supplied by City of Atlanta) that includes technical questions regarding an external vendor’s applications/systems. The questions focus on how/whether the application/system would impact the city’s network, what data encryption methods are utilized, what portals/ports must be open, etc.

b. Architectural Design Diagram: The City of Atlanta requires vendors to provide a pictorial depicting the components of the vendor’s proposed solution. The diagram should demonstrate how the vendor’s application software would connect to the city’s network and how users of the software would access the application.

2. Before deployment of new systems/applications to Production, the City of Atlanta requires approval by the IT Change Approval Board (CAB). A change ticket will be submitted and reviewed by technical resources to ensure that the application/system is ready for Production usage.

3. Changes to application functionality, operational workflow, and/or business procedures must be clearly communicated to all impacted City of Atlanta departments, via established communication channels including but not limited to email, Microsoft Teams, and other agreed upon methods. Changes that are visible to constituents must be communicated and thoroughly explained well in advance. The changes must be communicated at minimum at each of the following intervals: 30 days ahead of the change, two business weeks ahead of the change, one business week ahead of the change, one business day ahead of the change, and on the day of the change.

The vendor will work closely with a city assigned Project Manager to establish and execute a communication plan RACI that delineates specific responsibilities and expectations for communications for the duration of the project.

3.6 Documentation:

The vendor will be required to provide documentation regarding the modified or newly developed integrations, including but not limited to user manuals, configuration and maintenance manuals, database schema listings, and architectural diagrams.