BPLS Automation Planning and Implementation Guide

BPLS AUTOMATION
PLANNING AND
IMPLEMENTATION GUIDE
COMPUTERIZING BUSINESS PERMITS AND
LICENSING SYSTEMS IN THE PHILIPPINES
BPLS AUTOMATION
PLANNING AND
IMPLEMENTATION GUIDE
COMPUTERIZING BUSINESS PERMITS AND
LICENSING SYSTEMS IN THE PHILIPPINES
NOVEMBER 2011
DISCLAIMER
This document is made possible by the support of the American people through the United
States Agency for International Development (USAID). Its contents are the sole responsibility
of the author or authors and do not necessarily reflect the views of USAID or the United States
government.
TABLE OF CONTENTS
Acronyms v
Glossary vii
Acknowledgements ix
Message from National Computer Center xi
Foreword xiii
1. Introduction 1
1.1 Benefits of an Automated BPLS 2
1.2 Information Systems Strategic Plan 3
1.3 Guide Scope and Limitations 4
2. Impact on BPLS Standards 5

2.1 Unified Form 5
2.2 Number of Process Steps 5
2.3 Processing Time 7
2.4 Required Signatories 11
3. Readiness and Needs Assessment 12

3.1 Technical Working Group 12
3.2 Business Processes 12
3.3 Organizational Readiness 15
3.4 Infrastructure Readiness 17
3.5 Financial Readiness 18
4. Planning for BPLS Automation 24

4.1 Resource and Staffing Plan 24
4.2 Functional Specifications Document 28
4.3 Data Conversion and Migration Plan 28
4.4 Software and Data Integration Plan 30
4.5 Training Plan 32
4.6 Financial Requirements Plan 33
5. Managing the Implementation of the Automated BPLS 35

5.1 Vendors, Suppliers and Service
Providers 35
5.2 Software Licensing 37
5.3 System Support 38
5.4 Change Management 41
6. Sustainability of the BPLS Automation Reforms 45

6.1 Continual Process Improvement 45
6.2 Challenges for in Automating BPLS 46
6.3 Future Direction in BPLS Automation Reforms 46
Appendix A. BPLS Unified Form 49

Appendix B. Guide Questions for BPLS Streamlining Design 51
Appendix C. Functional Specifications Plan 52
Appendix D. IT Project Lifecycle 53
ILLUSTRATIONS
FIGURES
Figure 1.1 Inter-Agency Integration and Information Sharing 3
Figure 2.1 Process Flow for New Business Registration by
Functional Group 8
Figure 2.2 Process Flow for Business Renewals Consistent 10
Figure 4.1 BPLO Organizational Chart for Mixed
Implementation Team 27
Figure 6.1 Possible Future Process Step Reduction through
Computerization 48
TABLES
Table 2.1 Standard Five-Step Process for New Businesses 6
Table 2.2 Standard Five-Step Process for Business
Renewals 9
Table 3.1 BPLS Process Template 13
Table 3.2 BPLS Process Assessment Template 14
Table 3.3 BPLS Reform Action Plan Template 14
Table 3.4 BPLS Implementation Expense Items
by Category 20
Table 3.5 Breakdown of Additional Expenses 22
Table 3.6 Estimated Budget for BPLS Computerization
by LGU Size 22
iii
Table 4.1 Implementation Planning Staffing Composition 25
Table 4.2 In-House Staffing Matrix 26
Table 4.3 Mixed Implementation Staffing Matrix 27
Table 5.1 Service Level Gradient 37
Table 5.2 Industry Standard Issue Escalation Support Plan 37
Table 5.3 Support Service Gradient and Response Time 40
Table 5.4 LGU Change Management Programs
by Target Group 42
iv
ACRONYMS
BFP Bureau of Fire Protection

BIN Business Identification Number
BIR Bureau of Internal Revenue
BLGF Bureau of Local Government Finance
BOSS Business One-Stop Shop
BPLO Business Permit and Licensing Office
CDA Cooperative Development Authority
CHED Commission on Higher Education and Development
CICT Commission on Information and Communications Technology
COTS Commercial off-the-shelf
DENR Department on Environment and Natural Resources
DILG Department of the Interior and Local Government
DOF Department of Finance
DOST Department of Science and Technology
DRP Disaster recovery plan
DTI Department of Trade and Industry
FAAS Field appraisal and assessment sheet
FSD Functional specifications document
FSIC Fire Safety Inspection Certificate
GPL General Public License
ICT Information and communication technology
ICTO Information and Communication Technology Office
IEC Information and education campaign
ISMO Information Systems Management Office (formerly EDP/MIS)
ISP Internet Service Provider
ISSP Information system strategic plan
IT Information technology
JIT Joint Inspection Team
JMC Joint Memorandum Circular
LAN Local area network
LCE Local chief executive
LGU Local Government Unit
MOA Memorandum of Agreement
NCC National Computer Center
NSCB National Statistical Coordination Board
v
OLE Object linking and embedding
OR Official receipt
OS Operating system
PBR Philippine Business Registry
PDF Portable document format
PIN Property Index Number
PMT Project management team
PMO Project Management Office
POC Proof of concept
PSIC Philippine Standard Industrial Classification
RCD Reports of Collections and Deposits
RDBMS Relational database management system
SAM Support and maintenance agreement
SCR Summary of collection and remittances
SDC Smart data compression
SEC Securities and Exchange Commission
SEF Special Education Fund
SMS Short message service
SPI Standard Parcel Identifier
SQL Structured Query Language
SRE Statement of Receipts and Expenditures
SRS Systems requirement specification
SSS Social Security System
TDN Tax Declaration Number
TIFF Tagged image file format
TIN Tax Identification Number
TNA Training needs analysis
TOR Terms of Reference
TWG Technical Working Group
UPS Uninterruptible Power Supply
USRP Universal Polar Stereographic Standard Raster Product
UTM Universal Transverse Mercator
WMS Web Map Service
vi
GLOSSARY
Assessment (business permit and licensing context). Process of determining

the nature and condition of a business as reference for the license and permits fees and
proportionate value that is subject to taxation.
Bug. Software defect or flaw that prevents it from continuing to function or producing
intended results.
Business rules. Standardized procedures, rules, protocols or guidelines governing
assessment and taxation processes. Examples include the manner in which property values
are calculated.
Change management. Strategy to control and mitigate effects brought about by
computerization
Computerization. Management and execution of LGU work processes through the use
and application of information technology.
Customization. Process of adapting generic software to the needs of the LGU by
modifying software functions and features.
Data dictionary. Compilation of key terms to establish a common understanding between
the LGU and the software supplier, and within the LGU, of terms and concepts to be used
in computerization.
Data encoding. Process of transferring data from paper records to a computerized system.
Data migration. Process of transferring data from one computerized system to another.
Database. Structured body of information organized and stored in a system.
Enterprise architecture. The organizing logic of business process and IT infrastructure
reflecting the integration and standardization requirements of the firm’s operating model.
Enterprise architecture describes enterprise applications and systems with their relationships
to enterprise business goals. (MIT Center for Information Systems Research)
Functionality. Range of functions performed by software.
Framework. Basic conceptual structure for addressing and resolving complex issues;
design approach and strategy.
Hacking. Illegal entering of computerized system to access information without permission.
Implementation costs. Expenses incurred by the LGU during the execution phase of a
computerization project.
Internet service provider. Entity contracted by the LGU to provide access to the
Internet and other related services.
Local Area Network. Network of several computers connected to each other, the scope
of which is normally limited to a small physical space such as a house or an office building.
vii
Local Government Unit. Provincial, city, and municipal government offices.
Manual records. Paper and other similar media in which data are physically stored by the LGU.
Network administration. Process for managing and maintaining a computer network and
dealing with connectivity issues.
Post-implementation costs. Expenses incurred on a recurring basis by the LGU after
the conclusion of the computerization project.
Open source. A software development approach or model. Term used in referring to
platforms or software whose source codes are publicly available and can be modified and
copied freely by the user.
Platform. In computing, a platform describes some sort of hardware architecture or
software framework (including application frameworks), that allows software to run. Typical
platforms include a computer’s architecture, operating system, programming languages
and related runtime libraries or graphical user interface. (http://en.wikipedia.org/wiki/
Computing_platform).
Pre-implementation costs. Expenses incurred by the LGU during the preparatory phase
of a computerization project.
Procurement. Acquisition of goods, consultation of services, and contracting for IT
infrastructures by the procuring LGU. Refers also to the lease of goods or IT equipment.
Software. Computer program designed and created for a specific set of functions. Used
interchangeably with system.
Software license. A legal instrument governing the usage or redistribution of copyright
protected software. All software not in the public domain is copyright protected. A typical
software license grants an end-user permission to use one or more copies of software in
ways where such a use would otherwise constitute infringement of the software publisher’s
exclusive rights under copyright law. In effect, the software license acts as a promise from
the publisher to not sue the end-user for engaging in activities that would normally be
considered exclusive rights belonging to the publisher.
Supplier. General term for entity that, under a formal agreement, provides IT products and
services required by the LGU. Used interchangeably with contractor and vendor.
System administration. Processes for managing and maintaining servers and computer
systems.
Taxation. Process involved in the execution of tax collection functions of the LGU.
Valuation. Process used in determining the value of real property.
Web/SMS enabled system. System that permits users to conduct transactions, in full or
in part, and otherwise use software functions via the Internet or text messaging.
viii
ACKNOWLEDGEMENTS
Managed for USAID/Philippines by Nathan Associates Inc., LINC-EG—Local

Implementation of National Competitiveness for Economic Growth—is a three-
year project that began in 2008. LINC-EG assists policymakers in improving
the environment for private enterprise to establish, grow, create jobs, and help
reduce poverty.
This guide was developed under the LINC-EG Project to assist the Philippine
government in improving subnational systems for business permitting and
licensing. Consultant Maria Ferriols conducted extensive research with national
and local government officials at workshops, seminars, and one-on-one meetings.
The National Computer Center’s Officer-in-Charge Denis Villorente and
Directors Juli Sudario, Cheryl Ortiga and Visayas Group Head and eLGU Project
Manager Frederick Amores were particularly generous with their time. We thank
all of them for their advice and support. This guide would not have been possible
without their reviews, recommendations, and validation of research findings.
Ofie Templo provided administrative guidance for the research effort and the
guide also benefited greatly from analysis and editorial review by Mikela Trigilio
and Alid Camara of Nathan Associates Inc.
The contents are the sole responsibility of the authors and do not necessarily
reflect the opinion of the Government of the Philippines or USAID.
ix
x
MESSAGE FROM THE
NATIONAL COMPUTER CENTER
The National Computer Center (NCC), together with its partner organizations,
the Department of Interior and Local Government (DILG) and the Department
of Trade and Industry (DTI), would like to extend our appreciation to the
United States Agency for International Development (USAID) through the Local
Implementation of National Competitiveness for Economic Growth (LINC-EG)
Project for its support in the development of the Business Permit and Licensing
System (BPLS) Automation Guidelines.
The purpose of the BPLS Automation Guidelines is to provide the local

government units (LGUs) intending to automate their business registration
with advice on the planning and procurement of computer systems that will
be compliant with the service standards for processing business registration.
Moreover, this document is intended to aid LGUs in preparing their operations
for BPLS automation and to provide basic but concrete parameters to help them
manage the various stages of computerization - from planning to post-production
support.
This guide provides useful information for LGUs with operational BPLS systems
who are intending to either upgrade or extend the functionality of their current
system to meet the added requirements of the LGU.
All these are supportive of the national government’s objective of enhancing and
improving the investment climate.
Finally, it will serve as a good tool for the development and implementation of
BPLS systems in the LGUs which will help in moving forward the country’s drive
towards national competitiveness.
DENIS F. VILLORENTE
Officer-in-Charge
Office of the Director General
xi
xii
FOREWORD
USAID has supported Philippine local governments in improving the administration

of business permits and licenses since 2005, particularly in Mindanao. Through
partnerships with the World Bank’s International Finance Corporation and the
German government, this support has been scaled up to the national level and
extended to a number of local government units (LGUs). LGUs now recognize
the economic benefit of simplifying procedures and practices for issuing business
regulatory clearances. Streamlined and automated registration procedures are also
increasingly accepted as a means to reduce opportunities for informal payments
and as part of the overall anticorruption effort in the Philippines.
In July 2010, USAID/LINC-EG supported the national government in establishing

better service standards for business permitting and license systems (BPLS), such
as unified registration forms, limits on processing times, and simpler payment
procedures. Automation is recognized as an important means for implementing
those standards, but many LGUs face constraints in establishing and maintaining
a suitable electronic BPLS, or eBPLS. This guide aims to address some of those
constraints.
Large cities in the Philippines fully appreciate automation and several have
computerized parts of their treasury functions in recent years. Covering eBPLS
from strategic planning to implementation, this guide includes recommendations for
integrating treasury and real property tax assessment functions with streamlined
business registration procedures. The guide has two parts: a general guide to
strategic planning, including advice on how to deal with private sector service
providers, and a guide to baseline design that covers technical aspects of any
information technology solution, such as the design of hardware and software
specifications. This document covers the general policy issues. Building on the work
of other development partners who advocate automation, the guide offers up to
date and specific guidance to LGUs while recognizing that a sustainable eBPLS
solution for any particular LGU will depend on its financial, human, and other
resources.
We hope that this guide will be useful to national and local policymakers as
they embark on the next wave of BPLS reform, making automation a key part of
business registration and making administration of permits and licenses efficient
and transparent.
ALID DAVID CAMARA

Chief of Party, LINC-EG
xiii
1. INTRODUCTION
In his inaugural State of the Nation address last year, President Aquino directed local
government units (LGUs) in the Philippines to reform procedures to make it easier to start
a business.1 In response, the Department of Trade and Industry (DTI) and the Department of
the Interior and Local Government (DILG) launched the Nationwide Streamlining of Business
Permits and Licensing System (BPLS) program on August 6, 2010. An important aspect of the
program is the setting of standards for processing business permits and licenses in cities and
municipalities consistent with the 2007 Anti-Red Tape Act (ARTA). Guidelines for implementing
these standards are presented in the Joint Memorandum Circular No.1 series of 2010
(henceforth referred to as the JMC) signed by DTI and DILG on the same day.
The streamlining program has five components, one of which is the computerization of
business registration processes.2 While standards for business registration can be met with
manual operations, many LGUs, particularly in the National Capital Region (NCR), have found
that automation makes registration procedures more efficient.3 But many LGUs that want to
computerize are thwarted by lack of experience, financial capacity, and knowledgeable staff to
support and sustain computerization.
To address issues involved in LGU computerization, the Bureau of Local Government Finance
(BLGF) published Linking Up LGU Operations:A Guide to Computerization of Tax-Related Functions
in the Local Government Units in 2009. The guide provides LGUs with advice on aspects of
computerization, from planning to implementation, focusing on the automation of real property
taxes, but also in some measure on business registration. Given the drive to implement
standards consistent with ARTA, there has been a clamor for updated materials that LGUs can
use in meeting the BPLS requirements of the JMC.
The purpose of this document is to advise LGUs on the planning and procurement of computer
systems that meet the JMC’s service standards for processing business registration applications.
The guidance herein draws on the experience of about 17 LGUs in implementing various forms
of BPLS Automation. It does not cover procurement processes, technical system specifications,
or requirements and bidding processes for acquiring eBPLS solutions. For details on technical
specifications for BPLS computerization, please see the BPLS Automation Baseline Design Guide.
1 Aquino III, Benigno. 2010. State of the Union: Philippines. Available at http://www.gov.ph/2010/07/26/state-of-the-nation-address-2010
2 The other components involve mobilizing support for BPLS reforms, re-engineering processes, institutionalizing reforms, and improving
customer relations.
3 NCR cities that have automated BPLS procedures include Manila, Mandaluyong, Quezon City and Marikina. They were all part of the
Regulatory Simplification Project of the International Finance Corporation.
BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 1

INTRODUCTION
1.1 BENEFITS OF AN AUTOMATED BPLS

Computerization has immediate and long-term benefits for LGU operations: faster service and
more consistent outputs for business registrants; advances in LGU workforce productivity and
skills; compliance with standards becoming the norm of service; and citizens’ satisfaction with
government services and confidence in the government’s data and processes.
Computerization provides the Local Chief Executive (LCE) with a means for managing LGU
operations as a whole. It connects front-office to back-office operations (e.g., the activities of
the Business Permit and Licensing Office with assessment and collection by the Treasurer’s
Office), and provides the digital environment to properly organize and manage data quality and
speed of data exchange between LGU applications. The information received by the LGU will be
in a standard format and thus, easier to classify, manage, and consolidate.
Other benefits of automating registration include the following:

• Consistent Permit Requirements. Computerization helps make processes more consistent
for registrants. When registrants have a list of all requirements and corresponding
contact information, BPLO staff spend less time explaining requirements and the
potential for inconsistent communication of requirements is eliminated.
• Automatic Fee Calculation . With the automated BPLS automatically calculating fees due to
the LGU, the BPLO can produce accurate financial forecasts and performance reports.
The BPLS immediately categorizes payments into account groups upon receipt and
for every transaction. This eliminates the need to manually compute and record each
payment transaction in a separate spreadsheet or logbook.
• Expedited Approval. eBPLS eliminates the need for the LCE to sign each business permit,
as the electronic system immediately addresses document control and is capable of
processing LGU security requirements.
• Payment Tracking. eBPLS not only makes registration highly efficient, but also provides
LGUs with an accurate record of assessed fees payable to the LGU and of payment
transaction details that help track payment deficiencies. These records help LGUs to
work proactively with businesses in settling deficiencies and/or arrears.
• Monitoring and Evaluation. An automated BPLS provides LGUs with the data they need
to monitor and improve processes in a timely manner. Process steps or activities can
be monitored at a high level or a granular level because the BPLS logs and tracks the
amount of time each task takes.
• Data Integration. An automated BPLS allows the LGU to extract and share the
information of other national agencies to eliminate redundancy in the entry of business
registrant information (see Figure 1.1).
2 BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

INTRODUCTION
• Lower Costs. Making business registration forms downloadable from an online facility or
LGUs’ websites will decrease printing costs and make it less likely that LGUs will run out
of printed forms for registrants.
Figure 1.1
Inter-Agency Integration and Information Sharing
1.2 INFORMATION SYSTEMS STRATEGIC PLAN

Ideally, BPLS computerization should be part of an LGU’s Information Systems Strategic Plan
(ISSP), a three-year blueprint for using information and communication technology (ICT) in
fulfilling LGU functions. The National Computer Center (NCC), now under the Information
Communication Technology Office of the Department of Science and Technology (DOST), has
provided a five-step process for creating an ISSP, involving pre-planning, information systems
strategic planning, review of the ISSP by the NCC, approval/release of the ICT budget, and ISSP
monitoring.4
ISSP preparation is not mandatory for LGUs. While an LGU may embark on the
computerization of registration processes without an ISSP, an ISSP will be useful in securing
funding from external sources (e.g. banks, donors).5 Often, BPLS automation is not a stand-alone
activity but part of an LGUs’ revenue generating activities, such as real estate property tax
collection.
4 Refer to Executive Order 47 dated June 27, 2011.

5 The ISSP is important for agencies or LGUs requesting funding support from the NCC, the Department of Budget and Management, and
development partners. An ISSP approved by the NCC is the trigger for agencies to request DBM for budget support.

INTRODUCTION
1.3 GUIDE SCOPE AND LIMITATIONS

This guide provides information on assessing, planning, and implementing an automated
BPLS, covering requirements for financing, system maintenance and support, organizational
structure, and staffing. Section 2 explains how automating LGU operations will advance BPLS
standards. Section 3 will help LGUs assess business registration operations and presents the
steps necessary to reduce the number of process steps and comply with the JMC. Section 4
maps out the path of computerization: changes an LGU may need to make in order to simplify
processes; system functional and technical specifications; methodology to implement the system;
ICT infrastructure and staffing to support and maintain the system; and financial or budgetary
requirements for system implementation and support.
Section 5 provides guidance on vendor management, software licensing, and the support
and maintenance conditions the LGU must require from the vendor or system integrator
who implements the BPLS. Section 6 covers post-implementation management and continual
improvement, as well as issues that may arise in BPLS computerization, and governments’ plans
for promoting automation.

2. IMPACT ON BPLS STANDARDS
The DTI-DILG Joint Memorandum Circular (JMC) No.1 of Series of 2010 enjoins cities and
municipalities to meet four standards in procedures for securing a business permit: (1) use one
unified form for business registration; (2) limit to five the number of steps that an applicant has
to follow; (3) reduce the processing time to ten working days for new business applications and
to five days for business renewals; and (4) reduce the number of signatories. These standards
provide the framework for the computerization of business registration procedures.
2.1 UNIFIED FORM

Only one form should be required in applying for a new permit or in renewing a permit. The
unified form presented in Appendix A captures the data essential to lawfully grant a business
registrant the right to operate a business in an LGU. The form has fields that provide
• Information on the business (e.g., type and line of business, address, business area,
number of employees, capitalization, gross sales);
• An oath of undertaking, wherein the applicant promises to comply with regulatory
requirements within a period of time;
• Assessment of different business fees to be paid; and
• Verification of required documents.
In an automated BPLS, LGUs may be able to add on the form data unique to their locality.
It is recommended that LGUs adopt the basic structure of the BPLS Unified Form in any
computerized solution.
2.2 NUMBER OF PROCESS STEPS

A step refers to an action or actions that applicants and/or government agencies take in
applying for and processing business permits and licenses. The number of steps indicates process
complexity and the number of face-to-face interactions (or interfaces) between the applicant
and the government (local and national). Per ARTA, LGUs are encouraged to reduce the number
of steps to five for both new and renewed business permits.
Registration of New Businesses

Table 2.1 presents the standard steps and processing times for new business registration as
stipulated in the JMC and from the perspective of the applicant. These steps usually involve the
LGU’s front office, which functions as the Business Permit and Licensing Office (BPLO). The
applicant does not see the back office tasks and activities done by LGU units.

IMPACT ON BPLS STANDARS
Table 2.1
Standard Five-Step Process for New Businesses
Client LGU Timeframe
Documentary Required Best

Step Activities Requirements Offices Actions Standard Practice
1 Secure an Front Office – Provide
application BPLO application form
form List of
requirements
2 File application Completed BPLS Front Office – Written 1 day or less 5 – 10
for new Unified Form BPLO acknowledgemen minutes
business t receipt
permit SEC/DTI/CDA
Certificate of
Registration
Location Map and
Barangay Clearance
Occupancy Permit
Copy of FSIC for
Occupancy permit
Copy of Fire insurance
policy, if any
3 One-time All documents from Front Office – One-time 1-2 days or 5 – 15

assessment Step 2 Assessor assessment of less minutes
Back Office – taxes, fees and
BFP charges based on
Assessment documents from
inspection
reports
(Occupancy
Permit)
4 One-time Assessment of taxes, Front Office – Collect and issue 1 day or less 5 – 10
payment of fees and charges plus all Treasurer’s official receipt for minutes
taxes, fees & documents from Steps Office Cashier payment of taxes,
charges 2–3 Back Office – fees and charges
BFP
5 Claim business OR of taxes, fees and Front Office – Print, sign and One day or 10-15
permit charges paid and all BPLO release less minutes
documents from Steps Back Office – Mayor’s/Business
2–4 Mayor / Permit
Deputized
Signatory
SOURCE: DTI-DILG Joint Memorandum Circular No. 1, series of 2010.
Computerization will improve communication and coordination between front office and back
office personnel. Figure 2.1 provides an overview of the five-step process for new business
registration by the six functional groups involved:
1. Registrant. Completes required documents as indicated in the checklist provided by the
LGU in the application form.

2. BPLO. Front office processing and interface with business registrant.

3. Assessor. Determines fees associated with the application.
4. Cashier/Treasury . Collects any fees associated with the application.
5. Bureau of Fire Protection (BFP) and other LGU departments. Inspects the premises of
the business to verify that it complies with prerequisites for the granting of permits.6
6. Local Chief Executive. Grants final approval of business permit.
The red boxes indicate activities that may be executed in an automated BPLS set up.
Renewal of Existing Businesses

Steps involved in renewing business permits are presented in Table 2.2. The difference between
new applications and renewals is that renewal takes less time and requires fewer minor
processes. If the renewing business is compliant with all requirements and current on all
payments, LGUs need not issue a new registration plate or certificate. Instead, LGUs only issue a
renewal sticker (much like the Vehicle License Renewals) or a controlled and serialized stamp.
An applicant for renewal must still follow five steps but only five functional groups are involved
(see Figure 2.2). Business permit renewals do not require the LCE or his/her designate, as the
BPLO issues all renewal documents. The red boxes in Figure 2.2 indicate tasks that may be
performed by the automated BPLS.
Business renewals, which are considered simple transactions, should take LGUs five days to
complete, per ARTA. However, best practices in BPLS streamlining have established a standard of
less than one day for the renewal of business permits on off-peak periods, and 2-3 days during
the peak month of January. The LGUs are encouraged to target these benchmarks.
2.3 PROCESSING TIME

Processing time is the time spent by an applicant from the submission of the application form to
the LGU to receipt of the business permit. This period consists of transaction time, waiting time,
and travel time to/from the LGU business registration office. ARTA considers the processing of
new business applications a complex process that should take no more than 10 days, inclusive of
all processes performed by the LGU.
BPLS computerization will provide LGUs with the foundation needed to reduce its processing
time for new registrations to less than 10 days. Some LGUs that have already automated their
BPLS have reduced the number of steps to three or four.
6 These processes are owned and executed by offices external to the BPLO. Should parts of these inspection processes be computerized by
the external offices in the future, the BPLS will be able to handle data interchange between the systems.

8
Figure 2.1
Process Flow for New Business Registration by Functional Group
BUSINESS REGISTRATION (THE 5-STEP PROCESS) NEW APPLICATIONS
CASHIER / BFP & OTHER LGU

REGISTRANT BPLO ASSESSOR LCE
TREASURY DEPARTMENTS
Secure and
Review and
Complete Receive Conduct Site Review Registrant

Validate Payments
Application Registration Form Inspection Application
Due Mun/City
STEP 1
Form
Review Issue Assessment

Issue
Completeness of of Fees to Receive Payment
Approval Sign Business
Requirements Registrant from Registrant
Certification Permit
Schedule Site
Complete Inspection
Complete
Documentary NO (health, sanitation, Transmit Signed
Requirements? Issue OR
Requirements engineering, etc.) Documents to
BPLO
YES
Notify LGU
Submit Signed Enter Registrant
Department Heads
Registration Form Data into BPLS Route Proof of
or Schedule
to BPLO Software
BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

STEP 2
Coordinator Payment to Office
of the LCE
Review Assessed
Fees
STEP 3
Pay Assessed
Fees to Cashier
STEP 4
Pickup Issued
Permit and Post
Send Registrant LEGEND:
on Visible Area of
Notice to Pickup
Business
STEP 5
establishment BPLS Software Driven
Table 2.2
Standard Five-Step Process for Business Renewals
Client LGU Timeframe

Documentary Required Best
Step Activities Requirement Offices Actions Standard Practice
1 Secure form for Front Office Print and Process
business BPLO distribute time starts
applications application form in Step 2
with list of
requirements
2 File application Completed BPLS Front Office Written 1 hour 5 – 15
for business Unified Form BPLO acknowledgement minutes
permit renewal receipt; review
Previous business submission
permit
Statement of
gross sales from
previous year
3 One-time All documents Front Office One-time 1 hour 10 – 20
assessment from Step 2 Assessor assessment of minutes
taxes, fees, and
Back Office charges based on
Assessment documents from
by the Step 1 and client
Bureau of monitoring
Fire reports of JIT
Protection
(BFP)/Joint
inspection
Team
Reports
4 One-time Assessment of Front Office Collect and issue 1 hour 10 – 15

payment of taxes, fees and official receipt for minutes
taxes, fees and charges plus all Treasurer’s payment of taxes,
charges documents from Office (TO) fees and charges
Steps 2–3 Cashier
Back Office
Separate
Payment to
the Bureau
of Fire
Protection
(BFP)
5 Claim OR of taxes, fees Front Office Print, sign and 1 hour 10-15
Mayor’s/Business and charges paid – BPLO release minutes
Permit and all Mayor’s/Business
documents from Back Office– Permit
Steps 2 – 4 Mayor /
Deputized
Signatory
SOURCE: DTI-DILG Joint Memorandum Circular No. 1, series of 2010.

10
Figure 2.2
Process Flow for Business Renewals Consistent
BUSINESS REGISTRATION (THE 5-STEP PROCESS) RENEWAL OF PERMITS
BFP & OTHER LGU CASHIER /

REGISTRANT BPLO ASSESSOR LCE
DEPARTMENTS TREASURY
Secure and
Conduct Site
Complete
Inspection
Application
(BFP, LGU)
STEP 1
Form Review and
Receive
Validate Payments
Registration Form
Due Mun/City
Receive Payment
Issue FSIC &
from Registrant
LGU Cert. Of
Inspection Review Issue Assessment
Completeness of of Fees to
Requirements Registrant
Complete
Documentary
Requirements Issue OR
Complete Schedule Site
Requirements? Inspection
(health, sanitation,
engineering, etc.)
Submit Signed YES
Registration Form
to BPLO
BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

STEP 2
Enter Registrant
Data into BPLS Notify LGU
Software Department Heads
or Schedule
Coordinator
Review Assessed
Fees
STEP 3
Pay Assessed
Fees to Cashier
STEP 4
Route to Business Permits & Licensing Office
Pickup Issued
Permit and Post
Issue Certificate of LEGEND:
on Visible Area of
Renewal
Business
STEP 5
establishment BPLS Software Driven
2.4 REQUIRED SIGNATORIES

Signatories refer to the final approving authority or authorities whose signatures are affixed to
a business permit to make the document legal and binding under the law. Reducing the number
of signatories is a key reform that makes streamlining possible. The ARTA limits the number
of signatories for new or renewed business permits to five. Best practice recommends only
two. In some NCR cities, the Mayor, to avoid delays in the release of permits, deputizes the
Municipal/City Administrator or the BPLO to sign on his behalf. In addition, many LGUs require
department heads to sign every business application to ensure that applicants have completely
subscribed to the LGU requirements.
BPLS computerization will help maintain security, while expediting processing times and reducing
the burden on signatory authorities. The security features and workflow routing capabilities that
come as a standard in BPLS software packages minimize the need to have department heads
physically sign every application (new or renewals). Most security features are fully rules-based
so that LGUs can enforce specific business conventions as well as define explicit conditions that
would either automatically approve or flag an application (in cases of deficiencies in payments,
for example) that require the physical intervention of signatories.
Workflow routing capabilities are also fully rules-based to allow department heads and even the
LCE to act on or intervene in the processing of an application using handheld devices (such as a
mobile phone) or laptop computer even when away from the physical confines of their offices.
In eBPLS, all required signatories need not physically sign the required documents as digital
signatures are permitted under the E-Commerce Law or R.A. 8792.

3. READINESS AND NEEDS
ASSESSMENT
Before developing a BPLS implementation plan, LGUs should assess their processes,
operations, and technology environments. In evaluating the readiness of their organizations,
people, financing, and technical infrastructure to undertake BPLS automation, LGUs will also
determine what exactly they need to do in order to meet the efficiency standards stipulated
in the JMC. A readiness and needs assessment is also good way for LGUs to review and
update their approved ISSPs.
3.1 TECHNICAL WORKING GROUP

After the Local Chief Executive (LCE) commits to BPLS reform the next step is to organize
a technical working group (TWG) or BPLS streamlining team through an Executive Order.
TWGs are usually composed of the BPLO or the Treasurer as chairman and the heads of LGU
regulatory agencies involved in the BPLS process as members, namely, the BPLO, the City/
Municipal Treasurer’s Office, the City/Municipal Planning Office, the Local Council Chairman of
the Committee on Ways and Means, Office of the Building Official, Bureau of Fire Protection,
and the City/Municipal Health Office. The TWG’s main task is to steer the BPLS reform process.
This entails analyzing areas for reform, preparing the BPLS action plan, guiding members on
reform implementation, and assisting in formulating ordinances to support and institutionalize
the reforms.
3.2 BUSINESS PROCESSES

The first step in computerizing the BPLS is to determine which functions will be computerized.
The assessment of business processes is intended to help the LGU establish a baseline of
current processes and the level of effort required to bring them into compliance with the JMC
standards.
There are many approaches to analyzing an LGU’s business registration system. In the BPLS
manual prepared by the Local Government Academy, there are basically three steps involved
in the analysis: (1) preparing the current BPLS process table; (2) conducting the BPLS process
assessment; and (3) formulating an action plan for BPLS reform.
Prepare the BPLS Process Table

To begin diagnosing the current BPLS in an LGU, the TWG should document answers to certain
questions in the BPLS Process Template (see Table 3.1).

READINESS AND NEEDS ASSESSMENT
Table 3.1
BPLS Process Template
PROCESS TABLE
Description Input Process Output
Step Name Purpose No. of Documents Cost Office Location No. of Action Time to Output
No. of the Forms Required Signatories Process
Step
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
1
2
3
4
5
6
7
Total
Question Column
1. What steps does the applicant need to take to apply for registration? 1 and 2
2. What is the purpose (legal basis) of each step? 3
3. What documents does the applicant need to submit for every step? 4, 5
4. What is the cost for each requirement in the step? 6
5. In what office does the applicant accomplish the step? Where is it located (incl. floor number)? 7, 8
6. Excluding the applicant, how many persons from each office are involved in processing the step? 9
7. What activities or tasks are the persons in the office doing in processing the step? 10
8. How long (at the minimum, in minutes) does it take an applicant to walk to each office? How 11
long does s/he have to wait in line for an LGU staff member from whom something is needed (e.g.,
line number)? How long did it take for the LGU to process the transaction?
9. What does the applicant get (document or information) from the step? 12
Assess the BPLS Process

After completing the process table, the TWG should use Table 3.2 in comparing current BPLS
processes against standard practices. Processes or areas of concern (e.g., number of steps,
number of documents required, number of signatories, and processing time) are listed in
Column 1 in the table. In Columns 2, 3, and 4, the team should describe the current practice,
the relevant standard, and any gap between the two. For each gap identified, areas and strategies
for reform in place should be indicated in Columns 4 and 5. The guide questions presented in
Appendix B can be used in determining areas of reform.

Table 3.2
BPLS Process Assessment Template
1 2 3 4 5
Areas of Existing Benchmark/ Identified Areas of Reform
Concern Practice Standards Gaps Reforms Strategy
Steps
Documents
Signatory
Time
In documented best practices, BPLS reform strategies usually consist of taking steps to meet
standards. These may include properly sequencing steps in processes; setting up a business one-
stop-shop as a common venue for BPLS transactions; making joint inspection teams effective;
running information, education and communication campaigns; modernizing BPLS technology;
training staff; and establishing a legal framework for institutionalizing BPLS. Any gaps or areas for
reform are brought forward to the next stage of analysis.
Prepare the Action Plan

The format for an action plan drawing on the reform strategies listed in the assessment table
(Table 3.2) is presented in Table 3.3. The first step is to lift the strategies from the assessment
table. Each activity in the second column of Table 3.3 should be categorized according to a
schedule of implementation (one month, one quarter, one semester). It also important to define
expected results, date of implementation, responsible unit/person, required resources, and
support necessary at this stage.
Table 3.3
BPLS Reform Action Plan Template
Reform Specific Expected Date of Responsible Resources Support

Strategy Activity Results Implementation Unit/Person Needed Needed
List from previous What steps What will When are Who is on What are the What
exercise according to take? result from activities to be top? For whom inputs are internal/extern
to timetable. the steps? done? activities are needed? al supports to
done? do this?
Immediate –
within 1 month
Short-term –
I quarter
Medium-term -
1 semester
Long-term

The business process assessment activity is complete when the LGU is able to provide detailed
information on the following:
• The number of steps required to process a new business permit and the number of
process steps that need to be cut to comply with the JMC.
• The number of steps required to process a permit renewal and the number of process
steps that need to be cut to comply with the JMC.
• The average number of days it takes to process applications and issue a business permit;
the requirements needed to comply with the 10-day limit prescribed by the JMC for
new business applications and business renewals, respectively; and documented reasons
for BPLO operations that promote and/or inhibit the ability of the BPLO to meet the
standards.
To reduce the number of process steps, the LGU needs to review the following areas related to
business registration:
• The number of forms containing redundant data or data that is repeatedly entered (such
as personal information) in every form.
• The amount of unrelated data reflected on the registration form that will require
additional processing (recording, routing, or filing).
• The means and efficiency of communication between the BPLO and other agencies and
departments along with the effectiveness of Inspection Teams.
• Ordinances that hamper processing of business registration and affecting the number of
signatures (and signatories) needed before the LCE to approves an application.
3.3 ORGANIZATIONAL READINESS

The assessment of organizational readiness targets the LGU’s behavioral and structural
condition of the LGU in relation to BPLS computerization. Automating BPLS takes certain
organizational skills and those will vary from LGU to LGU.
Assess Readiness
Regardless of how many businesses are in an LGU’s locality, the TWG has to establish baseline
information for use in deciding on solution options and organizational development plans.
Organizational readiness for computerization may be assessed through surveys or through
self-assessment roundtables during which the TWG and the heads of key LGU departments
and sections answer questions and formulate action steps. Questions that could be included
in a survey are as follows:7
7 Based on Annex D of the BLGF’s Linking Up LGU Operations Manual.

1. Is there commitment at various levels in the LGU to computerize?

2. Has this commitment been translated into official documentation such as council
resolutions, executive orders, etc.?
3. Has the LGU institutionalized an Information Systems Strategic Plan (ISSP)?
4. Has the ISSP been measured against specific organizational objectives?
5. Have change management activities been planned?
6. Will the LCE be the executive sponsor of the BPLS computerization project?
7. Will the LCE designate a BPLS computerization project champion with the full authority
to form and lead a BPLS project team? When?
8. Will the Sangguniang Banyan support the BPLS computerization project with the
appropriate budget and ordinance to acquire a BPLS solution? When?
9. Assuming an ISSP has not been set up, will a specific project plan for the BPLS
computerization be developed? When? By whom?
10. Does the LGU have people who have the skills in the following areas:
- IT project management
- Process and systems analysis
- IT skills in office automation (e.g., word processing, worksheet processing, slide
presentations)
- IT skills in networking, programming, or database management?
11. Assuming the skills to computerize BPLS do not exist in the LGU, is the LGU prepared
to engage external resources to put in place the BPLS solution? When?
12. Will the LGU conduct change management, training programs and activities to prepare
its personnel for the roles they will assume in BPLS computerization? When?
The results of the organizational self assessment should be submitted to the LCE. The
assessment will form the basis for staffing a BPLS computerization project. Staffing requirements
will vary with the automation approach selected by the LGU and by project stage. Major stages
that will require different teams are as follows:
1. Process Streamlining
2. Implementation Planning
3. Implementation (Project Life Cycle)
4. Post-Deployment.


By the end of the organizational readiness assessment, the TWG should be able to tell the
LCE whether the LGU can carry out computerization independently or whether it should
seek assistance. The TWG should also be able to recommend a change management initiative
to prepare LGU personnel for the organizational and process changes associated with a
computerized environment.
The TWG will draft a document recommending the creation of a team that will plan for
the computerization of the BPLS. The TWG has to recommend if the team will have a
mix of internal and external manpower, depending on its assessment of the presence and
availability of such skills internally. The TWG may also propose to incorporate the skills into
the team (i.e., solicit expertise through letting bids, hiring people, or securing grants for
consultants).
3.4 INFRASTRUCTURE READINESS

Infrastructure readiness assessment refers to the technical infrastructure required to implement
an eBPLS.
Assess Readiness
At a bare minimum, the BPLO must meet the following infrastructure requirements:
1. An operational local area network (LAN), wire-based or wireless.
2. Servers available for a database server, application server, web server, network storage,
and backup server. The LGU must have at least two servers.
3. A minimum of 20 square meters of air conditioned space to securely house all servers
and networking equipment as well as IT staff.
4. At least one PC workstation for each functional (operations) station, each connected to
the LAN.
5. At least one laser printer and one impact printer. The laser printer will be used to print
reports on regular paper and the impact printer will be used to print on pre-printed
non-carbon forms.
The infrastructure readiness assessment should provide an inventory of computer assets as a

starting point for any additional acquisition of an eBPLS, depending on what solution approach
the LGU selects.


The inventory of IT facilities in the LGU will give the TWG the opening for the various
deployment options for an automated BPLS. If the facilities listed in the previous section are
available for use by the BPLS, then the LGU may choose to acquire the needed BPLS application
solution. It can be made to operate on the existing facilities, provided it has sufficient hardware
capacity to run the software.
If the IT infrastructure is suitable but is being used by other applications, or is more than three
years old, the TWG may need to prepare a plan for acquiring new hardware based on the BPLS
solutions method selected by the LGU. The LGU may also choose to build its own IT facilities,
whether a computer room or a full-fledged data center hosting all LGU computerized systems.
Details on how to acquire a data center are provided at the end of Section 4.4.
If the LGU chooses to have facilities hosted in an external data center, the TWG will have to
prepare a plan on what criteria will determine the selection of the data center. Except for the
inclusion of the BPLS standard application specifications, it will be a similar planning process
if the LGU opts to use a cloud computing vendor that will offer both the BPLS hardware and
software infrastructure as a service. Please see the eBPLS Baseline Design Guide for details on
eBPLS solutions and system requirements.
3.5 FINANCIAL READINESS

This activity is intended to determine the funds available to the LGU, or in some cases, the
LGU’s capital investment priorities, especially if the department targeted for improvement is
clearly a revenue generating entity.
Assess Readiness
When assessing financial readiness to implement a BPLS, the financial capability of an LGU to
absorb pre-implementation costs as well as post-production support and capacity development
costs must be considered.
Implementation and Recurring Expenses. The LGU must be prepared to secure the
initial capital outlay needed to computerize the BPLS. Table 3.4 provides a breakdown and
description of project-specific and recurring expenses (categorized by type) associated with a
BPLS computerization project. Required items are denoted with a check mark. The column on
quantity has been left blank as the final count (e.g., of number of software licenses) will depend
on the number of users in the LGU.

Table 3.4 provides the LGU with an idea of recurring project costs . Implementation planning,
for example, would likely require the LGU to retain experts in BPLS software implementation
to develop the project implementation plan. The same applies to post-production and capacity
development (such as technical training) to prepare LGU IT staff to support the new BPLS.
Additional Expenses. Table 3.5 details other software, service, and hardware expenses
that should be budgeted for.8 Of these expenses, only software support and maintenance are
recurring. Pre-implementation activities are a one-time expense, and all the other expenses
occur as needed. All costs are in addition to the project implementation cost but exclusive
of additional staff salaries and benefits as could be required by the BPLS computerization
project. Therefore, it is recommended that LGUs allocate no less than 32 percent of project
implementation costs in reserve for support and maintenance funds to ensure continued
software system availability.
Funds for the support and maintenance of the BPLS software system (or any computerized
system) must be allocated (if not reserved in advance) to ensure that the software system
continues to deliver the expected benefits throughout its usable life or until the LGU decides to
replace the system in the future.
Cost Ranges by LGU Size. Table 3.6 presents estimated cost ranges for implementing an
eBPLS, from pre-implementation through production. The approaches for these computerization
initiatives range from in-house development or outsourced development to customization.
Estimated cost ranges in the table assume that the LGU will acquire the components listed in
Table 3-4 and allocate for the support components listed in Table 3.5.
8 Exclusive of additional IT staff which could be required by the new processes and/or the BPLS.

Table 3.4
BPLS Implementation Expense Items by Category
Project
Expense Items Description Qty Recurring
Specific
SOFTWARE
Software licenses (server) License to install and use the server- !" "
based functions of an application. License
fees are paid for every physical server
machine in which the software is
installed
Software licenses (client access) End-user license (also referred to as !" "
client access license or CALs) to
connect and use server based functions.
This applies to both application and
database servers.
Software licenses (database) License to install and use the server- !" "
based functions of the database. License
fees are paid for every physical server
machine in which the database software
is installed
Software licenses (data Licenses paid to use proprietary data !" "
connectivity) connectivity software not accessible via
ODBC.
HARDWARE
Application server Machine where the application server !" "

will be installed.
Database server (in some BPLS Machine where the database engine and !" "
solution, the database and repository will be installed.
application are lodged in a single
server)
Web server (assuming that Machine where the web or HTTP server !" "
application is web-based) application will be installed.
PC workstations and peripherals Machines used by end-users to access !" "
server based applications.
15-inch LCD monitors !" "
KVM switch Equipment to allow a single monitor, !" "
keyboard, and mouse to control multiple
computers.
IMPLEMENTATION SERVICES
Project management !" "

Process consulting services !" "
Programming services !" "
Integration consulting services !" "
!" "

Project
Expense Items Description Qty Recurring
Specific
!" "
Training and courseware !" "
development services
Retainer-based services " !"
DATA CENTER
Construction (civil works and !" "

electrical)
Air-conditioning units !" "
Fire suppression !" "
Peripheral security !" "
Data center structured cabling !" "
Data racks and cabinet !" "
Uninterruptible power supply !" "
(20KVA)
Network patch panels Equipment used to connect cables from !" "
(structured) the different network nodes to the
networking equipment.
Network hub/switch/router !" "
NETWORKING
Network cabling (structured) !" "

Wireless networking receiver !" "
equipment
CONNECTIVITY
Domain name subscription !" !"

Web hosting !" !"
Internet subscription (ISP) " !"
SUPPORT AND MAINTENANCE
Annual software support " !"

agreement
Annual hardware support " !"
agreement
Hardware equipment parts " !"
Inventory
Equipment maintenance and !"
upkeep

Table 3.5
Breakdown of Additional Expenses
Expense Allocations Type / Frequency Description
Pre-implementation activities One-time expense 10% of the cost of implementation services
Software support and maintenance Recurring expense 22% of the license cost plus 8% for software
service repairs and maintenance (beyond the
signed support agreement)
Hardware support, repairs, and As need arises 5% of the cost of hardware equipment
maintenance (usable life of equipment)
Post-production activities As need arises 10% of the cost of implementation services
occurring after the warranty period
Training and continual improvement As need arises 10 % of the cost of implementation services
SOURCE: John R. Foster, Ph.D., Cost Factors in Software Maintenance, University of Durham School of Engineering and Computer Science,
1993.
Table 3.6
Estimated Budget for BPLS Computerization by LGU Size
Baseline Budgetary Requirements by LGU Size

BPLS Specific Cost Particulars Small Average Large
Pre-implementation PHP300,000.00 PHP 500,000.00 PHP 2,000,000.00
Implementation (software, hardware, PHP 3,000,000.00 PHP 7,000,000.00 PHP 15,000,000.00
services)
Post-implementation PHP 500,000.00 PHP 2,000,000.00 PHP 4,000,000.00
Production maintenance (at least 3 years) PHP 1,500,000.00 PHP 3,000,000.00 PHP 6,000,000.00
TOTAL PHP 5,300,000.00 PHP 12,500,000.00 PHP 27,000,000.00
It is understood that computerization project costs range anywhere from PHP 5M to more
than PHP 120M, depending on system functionality. In most cases, the solution includes more
than business registration functionality. The cost ranges above are average values confidentially
derived from LGUs participating in interviews and focus groups. The values provided by LGUs,
however, included computerization expenses that extend beyond the scope of BPLS to areas
of accounting, land mapping (GIS), real property tax mapping (RPTS), marriage licenses, and so
forth. The values are specific to, and representative of, the estimated cost of implementing an
eBPLS alone.

However, there will be instances when an LGU will have several alternatives to acquire the
automated BPLS solution at a cost lower that the lowest range in Table 3-6. Some solution
components may be acquired for free if (1) they are freely distributed like an open source
application; (2) they are provided as a grant by the government, multilateral organizations,
or private donors; (3) a solutions vendor has a socialized licensing policy that provides
discounting schemes based on the financial capability of the LGU; or (4) the LGU opts to
have minimal capital investment on computerization and just subscribe to a BPLS solutions
service.
It must be noted that the values are specific to BPLS and are exclusive of costs related to added
functionality, customized integration, or implementation of software systems not related to a
BPLS. The total cost of implementation will vary by the size of the LGU in terms of income or
the number of business entities it monitors and the transactions it manages on a regular basis.
LGUs with large business communities will naturally require larger servers, larger networks,
larger storage drives, more licensed end-users, and perhaps even more sophisticated software
functionality than LGUs with a smaller business community to support.
Also, the distribution of cost from pre-implementation to production maintenance is not

consistent with values in the table, given that computerization expenses vary by LGU and the
reality that until now, neither the DILG nor the LGUs have used a computerization costing
standard.

4. PLANNING FOR BPLS
AUTOMATION
Implementation planning specifies the basis and sequence of activities, staffing requirements,
deliverables, and financial requirements for the computerization project. Outputs include
(1) staffing requirements for planning, implementation, and post-deployment; (2) a functional
specifications document; (3) a data conversion and migration plan; (4) a software and data
integration plan; (5) a training plan; and (6) a financial requirements plan. Planning assumes that
the LGU has completed a needs assessment and has calculated the funding and budgetary
requirements specified in Section 4.6, below.
4.1 RESOURCE AND STAFFING PLAN

First, organize teams for various stages of the project. For the planning stage, the LCE must
establish a project management office (PMO) or project management team (PMT), with the
members of the TWG serving as ex officio members. Led by the LCE’s deputized representative,
the PMO should be comprised of representatives from IT and the different departments
involved in BPLS computerization.
Planning Stage
The PMO will organize a BPLS implementation planning team. Among others, the planning team
should include (1) a BPLO officer who understands BPLS processes; (2) a human resources
officer who can assist in determining the competencies of the LGU’s staff; and (3) Treasurer who
supervises the assessment and payment of BPLS fees. At this stage, preparing the functional and
process requirements of the project will depend on the TWG’s process assessment. Hence, it is
recommended that the planning team consult regularly with the TWG.
Table 4.1 summarizes staffing composition and identifies outputs, with corresponding manpower
and basic qualifications needed to produce those outputs. Should the LGU lack the skills
specified, it may be necessary to hire experts from professional consultancy firms, solution
vendors, or accredited IT schools whose faculty have BPLS computerization skills.9
9 The Commission on Higher Education (CHED) mandates that IT faculty members must have actual IT implementation experience to be
qualified to teach, and participation in the eBPLS project is one such opportunity.

PLANNING FOR BPLS AUTOMATION
Table 4.1
Implementation Planning Staffing Composition
Scope of Activity Staffing Requirement Basic Qualifications

Functional specifications plan Business Analyst At least two years as a business
analyst
Data conversion and migration plan Database developer or database At least two years as a database
administrator developer or administrator
Work and staffing plan and financial Project manager At least three years managing
requirements plan systems implementation projects
Training plan Training specialist At least two years in courseware /
training development and facilitation
Implementation (Project Life Cycle Stage)

Depending on the mode of acquisition chosen by the LGU, staffing for implementation will be
either all in-house (see Table 4.2) or a mixed team of in-house and partnered staff (Table 4.3).
Should the LGU lean more towards subscription to a cloud computing solution, personnel
specified in Tables 4.2 and 4.3 will not be required.
A mixed team of LGU staff and external partners is common in implementing a packaged
or customized BPLS solution. Team roles are complementary and provide multiple training
opportunities. Depending on the level of defined complexity and LGU staffing availability,
the LGU could dedicate LGU staff to participate in implementation or shadow the external
partner staff. The timing and degree of involvement of each staff member will depend on
the project phase and predetermined arrangements between the LGU and the contracted
party. Note that a headcount is not specified in Table 4.3. It may well be that the roles of
network administrator, database administrator, programmer, and data conversion lead are
lodged in a single person. Figure 4.1 presents a proposed organizational chart for a mixed
implementation team.
Post-deployment Stage
The LGU needs to plan, prepare, and allocate funds for three essential post-deployment
personnel prior to implementation: functional system administrator, technical system
administrator, and help desk support. The headcount per personnel type will depend on
the size of the LGU, the volume of transactions, the number of BPLS application users, the
extent of the network facilities, and the requirements to support BPLO operations. The
responsibilities of these staff are as follows:

• The Functional Systems Administrator is usually from the BPLO but is not necessarily a
technical specialist. It is more important that s/he knows the BPLS process from start to
finish. S/he will ensure that end-users are adept in handling the system, resolving process
issues, and trained in how to report problems to the technical team.
• The Technical Systems Administrator must be technically adept in networking, hardware,
operating systems, database management systems, and systems applications flow to
identify and isolate technical issues for resolution.
• The Help Desk Support must be a good communicator who can clarify issues for end-
users and technical supporters while monitoring and resolving issues.
Table 4.2
In-House Staffing Matrix
Assigned Activity In-House Project Team
Project Management Office LCE or duly appointed Representative as the Project Executive Sponsor
(PMO)
Committee Chairperson/s
Project Manager
Project management Project Manager
Process specialists / domain Front Office Staff
experts
BPLO Supervisor or Manager
Taxation Specialist / Treasury
Technical support IT Manager
Network Administrator
Programming and software Technical Lead
development
UI Developer / Graphic Designer
Application Developer/Programmer
Database Developer
Data management and Database Administrator
conversion
Data Conversion Team
Training Training Group

Table 4.3
Mixed Implementation Staffing Matrix
p ff g
Assigned Activity Internal LGU External Partner
Project Management Office (PMO) LCE as Project Executive Sponsor Project Manager
Committee Chairperson/s Client Management Officer
Project Manager
Project management Project Manager Project Manager
Process specialists / domain Front Office Staff Business / Process Analyst
experts
BPLO Supervisor or Manager
Taxation Specialist / Treasury
Technical IT Manager Technical Lead
Network Administrator Functional Specialist
Database Developer
Application Developer
Data management and conversion Database Administrator Database Administrator
Data Conversion Team
Training Training Group Training Specialist
Figure 4.1
BPLO Organizational Chart for Mixed Implementation Team
PROJECT MANAGEMENT
OFFICE
LGU PARTNER
PROJECT PROJECT
FUNCTIONAL BUS/PROC
SPECIALISTS ANALYST
TRAINING FUNCTIONAL
SPECIALIST
GROUP
TRAINING
LGU IT MANAGER
SPECIALIST
DATA TEAM NETWORK DATABASE TECH LEAD
CONVERSION ADMINISTRATOR ADMINISTRATOR
DATABASE APPLICATION
DEVELOPER DEVELOPER

Early on in planning, the BPLO Head should coordinate with the IT Head or an equivalent
designate (such as a member of the IT department) to prepare a staffing plan that includes job
descriptions and a proposed budget. The staffing plan should be approved by the LCE or his/her
deputized counterpart.
4.2 FUNCTIONAL SPECIFICATIONS DOCUMENT

The functional specifications document will provide details on operational processes;
organizational structure and staffing; the ICT environment; integration requirements; training;
and budgetary requirements. The basis for a project work plan and schedule, it should be
disseminated widely, and should contain recommendations from the assessment, TWG, and
public stakeholder groups on processes and functions that must be in the eBPLS.10 A template
for the functional specifications document is presented in Appendix C.
4.3 DATA CONVERSION AND MIGRATION PLAN

Before engaging in a full-blown BPLS automation project, the project team will need to quantify
data requirements. Data conversion, for example, means converting records from their original
state to an electronically accessible format that can be used by the automated BPLS. The effort
required to convert data must be taken into account. The higher the number of records stored
in physical, non-electronic format, for example, the longer conversion will take. The different
states of data are as follows:
• Manual physical records (loose-leaf) are on separate sheets of paper and stored in separate
locations (usually in a department filing cabinet or drawers of individual desks).
• Manual physical records (organized and filed) are stored in a dedicated physical location
such as in a filing cabinet or library in the form of record books, logs or ledgers.
• Manually updated electronic files or spreadsheets are records created using a word
processing or spreadsheet tool (such as MS Office Word or Excel) and stored on the
hard disks of individual computers or in shared network folders.
• Application-specific data are electronic records stored in the individual back-end databases
of software applications currently used by the LGU but inaccessible to other software
applications.11
• Centrally managed data repository consists of electronic records created and stored using
a relational database management system and accessible by other authorized software
applications of the LGU.
10 For more information on technical specifications compliant with JMC standards, see the NCC’s eBPLS Baseline Design Guide. The guide
covers (1) the baseline process and software flows; (2) required core software features; (3) entity relationship model; (4) data interchange
and integration; and (5) basic software and hardware systems specification.
11 If the application uses a proprietary and non-ODBC (open database connectivity) compliant database, the LGU will need to purchase
additional connectivity licenses to allow external applications to extract data from the proprietary application’s database or allow external
applications to directly interface with the application’s back end databases.

Before data can be converted it must be cleaned and migrated. This usually takes a substantial
amount of time depending on the state, volume, and mix of manual and digital records. Data
cleansing or “scrubbing” involves identifying incomplete, corrupted, duplicated, inaccurate,
irrelevant parts of the data and then correcting, modifying, replacing, or removing this “dirty” data.
Data conversion tasks can range from simple copying and pasting into a predefined, structured
electronic format, to scanning physical documents as an image that can be referenced by the
application, or to complete reconstitution wherein the details of every record are manually
entered into the target database application.
Where the LGU uses electronic spreadsheets or documents to store data, conversion will
likely require a data conversion program. These programs can be custom-developed using a
spreadsheet application like MS Excel, or open source ETL (extraction, transformation, and load)
software products such as Apatar, to automate the process of extracting data from an electronic
source, transforming the data to match the specifications of the target database, and finally,
migrating the data into the target database tables.
Data conversion must cover the transformation of the following LGU records from the current
state to the target electronic/digital format as would be required by the automated BPLS:
• Business owner/registrant personal information
• Business entity information
• Business payment details and history
• Business liabilities and penalties
• City/municipal street reference and Barangay names
• Property Index Numbers.
There are two types of data conversion activities: digitizing and normalizing. Digitizing is to
convert manual records into an electronic format. Depending on the readiness of the BPLS
software, manual records could be directly encoded into the software. If the source data
requires scanning, digitizing will require a high-resolution scanner to convert the physical
document into an image that can be stored as a file in the automated BPLS. The scanned image
could then be uploaded into the automated BPLS as a reference for an existing record.
Normalizing is to convert data already in electronic form into the format required by the BPLS
software. Normalizing could be entirely automated as follow:
• Load source data directly to reference tables. The type of data loading tool will
depend on the degree of transformation required by eBPLS. For data that will be

loaded directly to reference tables, simple data loading tools or the data import
function of the BPLS software will suffice. Before loading data directly into the
target tables, it is important for data loaders to ensure that each source record’s
form, structure, type, and completeness complies with the requirements of the
automated BPLS. Loaded data that does not comply will produce errors and could
even render eBPLS unusable.
• Load source data via the BPLS Automation User Interface (UI)12. For data to be loaded using
the UI, a UI-loader tool is recommended. This tool loads the source data using the user
interface of the system as though it were entered by an encoder – only faster. Loading
data via the UI subjects each loaded record to the validation controls and rules of the
BPLS application.
A quality assurance method for the conversion process will ensure data accuracy and integrity.
One simple method is to enter data twice and compare results, then correct any disparities. For
more complex data conversion, quality management and statistical quality control techniques
may be used as foundation for the quality assurance method.
4.4 SOFTWARE AND DATA INTEGRATION PLAN

Software and data integration requirements will differ depending on the product,
implementation path, and service provider chosen by the LGU. eBPLS will either be a
standalone system (installed on a single pc workstation), a client-server system, or a web
application. In most existing LGU solutions, The automated BPLS will interface and be
integrated with the other functions and applications, including computerization of BPLS
processes covering inspections. If the automated BPLS system will be integrated with
other systems, it is prudent to include the required application and database capabilities
in the planning documents.
Overall Integration
If high levels of software and data integration are required, the following steps are
recommended:
Software Integration
1. Analyze all required software applications that will be integrated into the BPLS software
and assess the functional, operational, and approval flows that will be affected as a result
of the integration.
12 A user interface is a system by which people (users) interact with a machine. The user interface includes hardware (physical) and software
(logical) components. User interfaces exist for various systems, and provide a means of Input, allowing the users to enter and manipulate a
system, and/or Output, allowing the system to indicate the effects of the users’ manipulation. http://en.wikipedia.org/wiki/User_interface.

2. Identify the important points of integration and minimize the number of points. Take note
that software integration, unlike data integration, would result in the ability of eBPLS to
transact as though it were a part of a single system and vice-versa.13
3. Document the software integration requirements.
4. Have the department heads whose units will be affected by integration agree on a set of
policies and procedures on managing the addition/omission of process steps as a result
of software integration.
Data Integration
1. Conduct a full data compatibility analysis of source and target data, identifying connectivity
methods and security restrictions of source and target data sources.14
2. Assess the functional, operational, and approval flows that will be affected as a result of the
data integration.
3. Define the data elements that would be exchanging or updating values and minimize
the number of bi-directional updates as these will severely affect overall database
performance.
4. Document data integration requirements (this is also referred to as a detailed data
integration mapping document).
5. Have the department heads whose units will be affected by integration agree on produce
a set of policies and procedures on managing these changes in operations.
After completing these steps, the planning team should consolidate the software and data
integration requirements into a single software and data integration plan.
Integration with the Philippine Business Registry

An important consideration in the Automated BPLS Software and Data Integration Plan
is the inclusion of the computerized Philippine Business Registry (PBR). The PBR system
is being upgraded and is not yet fully operational but its design and objectives warrant
integration with the automated BPLS.
The PBR is a web-based system that a business registrant can use to register his business
anytime and anywhere using the internet. An LGU is e-ready if the BPLS operates an
automated BPLS and if it has a good Internet connection. Connecting the e-ready LGU
requires the following:
13 Refer to Annex C - National Data Exchange Standards, Linking Up LGU Operations – A Guide to Computerization of Tax-Related Functions
in Local Government Units, Bureau of Local Government Finance © 2009, pp 51-55 (ISBN 978-971-93448 1-0).
14 This task should be accomplished by the designated database administrator (DBA).

• A staging server connected to the Internet. This server will allow the automated BPLS to
extract information about the business registrant from the PBR, thereby saving the
registrant time in entering data required by both the PBR and BPLS. This approach
requires that the LGU’s automated BPLS be connected to the PBR while registration is
occurring. Extraction from the PBR is real-time.
• A program that allows the staging server to upload and download data between PBR and the
existing computerized registration and licensing system. The downloaded tables from the
PBR will be used by the automated BPLS as its master reference table for extracting
data about its business registrants. This approach will allow the automated BPLS to be
on a stand-alone mode, using the PBR tables, already lodged in its system, as a master
database. Extraction from the PBR may be an end-of-day process and need not be real-
time. Internet connection may be scheduled.
• Internet kiosks that allow applicants at LGUs to register directly. This approach is exactly
like the first approach except that registration is self-service. It is the registrant who
encodes entries instead of a BPLO staff member. Authorized BPLO personnel will still
verify the prerequisite documents. Fees will be paid through the Cashier or Treasurer’s
office.
In all the options enumerated above, the automated BPLS design requires that a key data item
be indexed to match a key data item in the PBR database. This will allow the smooth interface
and integration between the data from the two systems. This has been included as part of the
database schema in the BPLS Automation Baseline Design Guide.
Data Center Integration

An automated BPLS needs relatively little space so it is unlikely that deployment will require
building a data center. But an LGU may want to procure a data center if its autoamted BPLS is
to be housed within its premises. If not, other options include (1) co-locating IT infrastructure
facilities in an external data center run by another government agency or a private firm, and
paying co-location fees for the use of other IT facilities; (2) renting the total IT infrastructure
of the data center, including servers and networks; or (3) purchasing BPLS services on a
subscription plan. In the last two options, the LGU need not acquire any hardware. See the BPLS
Automation Baseline Design Guide for detailed specifications.
4.5 TRAINING PLAN

The functional specifications document is the basis for defining training requirements. Where an
LGU lacks resources to develop a training program, the planning implementation team should
consider hiring experts in automated BPLS and LGU business registration.

The training plan should be based on a training needs analysis (TNA) of end-users and technical
personnel. Training materials should then be designed to cover the automated BPLS process (or
changes to current processes), changes or updates to policies and procedures, use of automated
BPLS to perform duties and job functions, and specific functional requirements of end-users. As
outlined above, the materials must address the requirements of the implementation stage, the
particular topic and subject matter, and the targeted training participants.
Materials should be organized into modules for key staff functions (e.g., customer service,
assessors, BPL officers, managers, and IT systems administrators). During the planning stage, it
will be expedient for the planning team to be trained on the features, functions, and capabilities
of the various automated BPLS solutions. This will allow them to understand the process
and systems flow, the reports that will be generated, and the skills that will be needed during
implementation and production.
During the implementation stage, project team members should be trained on systems
implementation methodology. This training should cover development of skills in identifying and
documenting processes, describing and recording functional tasks, defining differences and gaps
between current processes with automated BPLS solution options, specifying business rules and
conditions to test the validity and fit of the automated BPLS solution options, and determining
the condition of valid and trustworthy data. The training should enable the project team to test
the eBPLS against live data in a pilot environment and report issues and incidents that should be
addressed or revised to ensure that the systems processes are accurate or bug-free.
The personnel who will eventually operate and administer the automated BPLS should also be
trained to identify, document, report, escalate, and monitor the resolution of system problems,
issues, or bugs. Training should include skills for handling user inquiries, help desk support,
assistance in the usage of the automated BPLS, and identifying points of enhancement for the
automated BPLS solution. On the technical side, IT personnel should be trained in database
administration, systems administration, managing security and access to the system, application
and testing of systems upgrades and software patches updates, and to some extent, debugging.
For BPLO front liners, training should include assistance to business registrants to interact with
the automated BPLS solution. As end-users of the automated BPLS, they should be trained on
system navigation, data handling, and the operation of workstations and computer peripherals.
4.6 FINANCIAL REQUIREMENTS PLAN

In addition to assessing financial readiness as covered in Section 3.5 above, LGUs should
determine the total cost of ownership (TCO) for its eBPLS solution. Calculating the TCO
is an industry practice used to determine the funding or budgetary allocations required to

operate the system throughout its usable lifespan. The TCO is the sum of all expenses related
to the operation of the automated BPLS throughout the system’s usable lifespan. It includes the
following:
• Cost to implement the solution inclusive of software, hardware, services, and support.
• Recurring software and hardware support costs.
• Staff training (functional, technical, and administrative).
• Parts replacements and hardware upgrades (as required by and specific to the solution).
• Subscribed services, such as ISP subscription for internet connectivity.
• Construction costs specific to the solution, such as civil, electrical, and heating,
ventilation, and air conditioning (HVAC).
• Salaries and benefits of additional internal staff (BPLO and IT) needed to support the
new processes and system.
• Professional consulting fees (incurred after deployment) to enhance or customize the
system.
• Consumed power and utilities (inclusive of fuel costs for generator or GenSet
operation).
Cost particulars can be consolidated using the functional specifications document, the data
conversion and migration plan, the software and data integration plan, the resource and staffing
plan, and the training plan.
On the basis of these cost items, the implementation planning team can prepare the budget
requisition using the prescribed LGU form detailing the cost particulars of the BPLS automation,
making sure to indicate the additional operational expenditures that would be required to
support and maintain the system in the production environment.
In addition to the LGU budget, other potential sources of financial assistance for LGUs’
automatedBPLS projects include the following:
• Donations or grants from funding agencies, multilateral organizations, or private entities.
• Municipal Development Fund from the Department of Finance.
• Service offerings of private banks for average daily balance of deposits made by the LGU.
• Loans from private banks.
• Loans from government banks (DBP, LBP).
• Official Development Assistance funds.
Once the budget for the project has been drawn up and a decision on the funding source is
made, the proposed budget can be submitted to the BPLO and IT department heads for review
and approval, including any necessary endorsements required by LGU ordinances. The reviewed
budget proposal can then be submitted to the LCE for final approval.
5. MANAGING IMPLEMENTATION
OF THE AUTOMATED BPLS
How the automated BPLS is implemented depends on the acquisition option chosen by the
LGU, as described in the BPLS Automation Baseline Design Guide. If the LGU selects a packaged
solution, implementation will focus on setting up parameters, training users, creating a
conference room pilot of the automated BPLS, and mapping data into predefined tables. If it
decides to develop a solution from the ground up, implementation should probably follow
the traditional systems development life cycle (SDLC): (1) definition of activities; (2) technical
design; (3) development; (4) testing; and (5) deployment and training (see Appendix D). For a
customized package solution, implementation may combine a rapid implementation method with
SDLC. All these methods can vary depending on developers, vendors, or partner consultants.
And for any of them, the LGU is likely to engage external personnel to assist with eBPLS
implementation coming from vendors, suppliers, and service providers.
5.1 VENDORS, SUPPLIERS AND SERVICE PROVIDERS

Maintaining a good relationship with vendors, suppliers, and service providers throughout the
project lifecycle is important to delivering a working BPLS environment in the contracted
timeframe. The amount of interaction between the LGU and the service providers will vary by
project stage. Below are suggestions for managing relationships by project stage.
Pre-Bidding to Contract Award

Interaction and management of interested vendors from the pre-bid to contract award must
comply with the provisions of RA 9184 (Government Procurement Reform Act). The BPLO
should designate a single point to be the official communication channel and distribution
point for all documents (e.g., systems requirement specifications, terms of reference, and bid
documents). The BPLO point of contact should keep a detailed record of all communication
between all interested suppliers during the initial stages of the process. Regular meetings should
be organized to update LGU stakeholders on project status and issues that may arise during
each step leading to contract award.
Implementation to Go-Live
A project management office (PMO) should be established and be led an Executive Project
Manager (PM) appointed by the LCE. The partner’s project manager will be a member of the
PMO and will report to the PM.

MANAGING THE AUTOMATION OF BPLS
A refined project implementation schedule should be created as the master schedule and
agreed on by the PMO. The project team will update the schedule and submit it to the PM
weekly or as often as required by the LGU. Schedule changes will be tracked and given a version
number using an agreed on numbering convention.
Project meetings should be scheduled weekly to track activities and deliverables, and to
resolve problems. These meetings should be attended by the PMO and senior members of the
project team. The basis of a good relationship between the LGU and supplier is transparent
communication and expeditious action. The LGU should give the partner with a reporting
template that the partner’s project manager will submit on a weekly basis, with a copy sent to
all members of the PMO. LGU designates should act expeditiously to bring unresolved issues to
the attention of the LCE or department heads.
All project communication between the project team members should be documented using a
common format transmitted through a project memorandum or via electronic mail, with a copy
sent to all members of the project team and the PMO. The project team should keep two sets
of project binders containing all project documentation, one stored in a secure location and the
other in a location accessible to all members of the project team.
Post-production Support
Prior to the scheduled go-live date, the PMO should review the support agreement that
accompanied the implementation contract of the software vendor and the implementation
partner to help the LGU define the committed support level suitable to the eBPLS operational
requirements. The support agreement (post-production) must be updated and renegotiated to
reflect any additional system support requirements defined during the implementation phase.
In addition, the heads of the BPLO and IT departments, and the post-production support
partner will need to do the following:
• Designate a staff member to serve as the in-house help desk. The help desk is manned by
an information and assistance employee who helps troubleshoot problems in the eBPLS
applications and infrastructure.
• Define and agree on a service level agreement (Table 5.1).
• Define and agree on a standard issue escalation plan (see Table 5.2).
• Define and agree on a standard issue tracking procedure.15
15 The IT department typically manages all system help desk support. It is recommended that IT have software to track and manage support
issues. IT is also responsible for escalating issues to the next escalation level depending on the severity of the support issue that was raised
(Table 5.2).

Table 5.1
Service Level Gradient16
99.0000% 99.9000% 99.9900% 99.9990% 99.9999%
Uptime (hrs.) 8678 8757 8765 8766 8766
Downtime (days) 3.65 0.37 0.04 0.00 0.00
Downtime (hrs.) 87.66 8.77 0.88 0.09 0.01
Downtime (min.) 5259 526 53 5 1
Table 5.2
Industry Standard Issue Escalation Support Plan
Issue Escalation Level Designated Support Group

Level 1 Functional Specialists
Level 2 System Administrators
Level 3 IT Group
Level 4 Software Vendor Support Group
5.2 SOFTWARE LICENSING

The End-User License Agreement (EULA) contains the licensing parameters of commercial
software specifying the use of the software by end-users. The source code of a commercial-off-
the-shelf (COTS) software BPLS product is the intellectual property of the software vendor.
Unless the BPLS software is packaged as an open source product (GPL License), it is illegal for
end-users to reverse engineer, customize, or tamper with the compiled code running on any
of the end-user’s computers. In most open source licensing schemes, any modification of the
source code must be made open source as well.
A proprietary BPLS application disallows its licensees from tampering with any aspect of
their compiled system. However, proprietary systems do provide the capacity for its users to
customize specific high-level functions or even attach customized functions to its core engine
but only through the use of defined software adapters or middleware. Only the customized
features of the software are owned by the LGU and only if the contract with the system
integrator clearly specifies that all development work is “work made for hire” (i.e., the LGU paid
to have these modules, features, and functions developed specifically for its own use).
16 The number of uptime/downtime hours is based on the annual constant of 8765.76 hours per year. It must be noted that service level
commitment (SLC) and system availability requirements (SAR) higher than 99.0000% exponentially increases the support or subscription
costs of the LGU. In most cases a service level commitment of 99.0000% uptime will be adequate to the computing requirements of LGUs.

For proprietary BPLS applications, it will be prudent for the LGU to require that a copy of the
source code of the production version of the software be held in escrow in a safety deposit box
of a trusted organization like a bank. Should the developer cease to exist, the LGU will have the
rights to read, examine, modify, and upgrade the software source code of the BPLS. If the LGU
engages a contractor to develop an automated BPLS solution from the ground up, the LGU
owns every output of the contractor from design to final working system, provided that this is
clearly stipulated in the service contract.
5.3 SYSTEM SUPPORT

Pre-implementation, implementation, production, and post-production support are four areas
of support that the LGU should require from software vendors and implementation partners.
Support conditions should be specified in the Master Services Agreement, Engagement
Contract, and itemized in the Support and Maintenance Agreement (SAM) issued by the
software vendor or the certified implementation partner before the implementation stage. It is
therefore imperative that the LGU raise questions about or ask for changes in the SAM before
implementation.
The LGU needs to ensure that all aspects of the system are covered by a SAM (e.g., software,
customizations, hardware). Although it is unlikely that users will need to customize hardware, it
is nevertheless important to ensure vendor support for each unit used in production. Software
vendor support agreements only cover the non-modified or non-customized version of their
software product deployed in the LGUs’ production environment. Software vendor support
will not normally cover any customized functions. The LGU must require the developer or
systems integrator who performed the customization to support the customized features as
customization is beyond the scope of any vendor’s support agreement.
Pre-Implementation Support Services

The pre-implementation stage educates LGUs about the products and suppliers. Potential
partners need to provide the LGU with support in the following critical areas:
• Proof of Concept (POC) Environment. To give the LGU a chance to “test drive” the
solution, the POC environment consists of all functional software, hardware, and
system consultants. The LGU should ask vendors to make system consultants available
throughout the POC period to support LGU staff in the roll-out of the automated BPLS.
In a POC setting, the burden of bringing all components of the system together is the
vendor’s exclusively. The LGU will provide secure facilities where the POC environment
can be set up and the staff or team designated to test drive the system.
• Production Visitation. It is recommended that the LGU request that the vendor schedule
visits to the sites where the automated BPLS is used in a production environment. The
visits will allow LGU representatives to interview users from each site.

• Pre-implementation Immersion Workshops. Software systems are smoothly implemented

when stakeholders share a common understanding of the system and are immersed in
its features and capabilities. LGUs should request that the software vendor conduct of
immersion workshops before the start of the implementation stage to help stakeholders
understand the software and what it takes to implement the system in the LGU.
Implementation Support Services

During the implementation stage vendor should provide the following:
• Application software support (configuration, patches, bug fixes, etc.) and documentation.
• Database software support (configuration, patches, bug fixes, etc.) and documentation.
• Systems testing support.
• Integration and middleware support and documentation.
• Deployment support and certification (applications and database).
• Hardware support (server configuration, security patches, etc.) and documentation.
• End-user, systems administration, and technical training (training on all technologies
required to sufficiently manage the system as a whole) and courseware documentation.
Time constraints during the implementation stage of a project make response time on support
requests critical. The LGU should define these response times since delays will affect the
delivery timeframe of the project. As a matter of convention, software vendors match their
response time to support requests based on the severity of the issue raised. Response times
could range between four hours to several days, and in most cases, software vendors response
within four hours only for in-production systems.
The response time or service level commitment specified in the SAM issued by the software
vendor or its certified partner must not be confused with resolution time. The response time
specifies how quickly the vendor’s support group is committed to respond to issues posted by
the customer. The vendor’s support group will typically ask the customer to follow a series of
diagnostic steps, download and run a diagnostic program, or open a log file to help determine
the root of the problem. The speed of resolution depends on the condition of the system as
revealed during the diagnosis.
Customized systems are technically beyond the scope of conventional support agreements.
Unless a customized support agreement between the LGU and software vendor specifying
the aspects that will remain “supportable” is in place, the customized part of the application
will not be covered in the support agreement. As a matter of practice, support agreements for
customized applications will need to be made between the LGU and systems integrator or
developer who created the customized functions or modules.

Production Support Services

Production support begins as soon as the system is deployed in a production environment.
Software vendors provide a defined support gradient as shown in Table 5.3. If the running
eBPLS application is a customized version, only the unchanged portion or functionality of the
system will be covered in the support agreement. The LGU should require the developer of the
customized portion of the system to support the customized features or modules.
Table 5.3
Support Service Gradient and Response Time
Service level commitment

Condition Severity
(maximum response time)
System is down. All work has stopped. Severity Level 117 8 business hours
System is operational but certain functions that affect Severity Level 2 16 business hours
work are inoperable.
System is operational but errors or program exceptions Severity Level 3 24 business hours
occur infrequently. Exceptions do not affect work.
Software Updates or Security Patches need to be Severity Level 4 5 business days
applied
Annual support agreements are fee-based. By industry standards, the amount payable to the
vendor or support group ranges from 15 to 25 percent, averaging around 22 percent of the
total implementation fees (refer to Table 3.6). In some cases the first year payment for the
annual support and maintenance fees are bundled into the total amount paid to the vendor. The
LGU needs to clarify the following support parameters:
• Total hours of onsite support covered under the annual support agreement. It is
important for the LGU to determine how the vendor computes the number of hours
per visit. Most vendors immediately compute (or charge) an onsite visit at 8 hours even
if the actual work only took 30 minutes and is deducted from the total allowed number
of visits as stipulated in the support agreement. The LGU must require the vendor to
provide the following categories of onsite support:
- Technical support (applications, database, integration, and data connectivity).
- Functional support (application configuration, workflow routing, etc.).
- Training and immersion support.
• Total hours of telephone-assisted support covered under the annual support agreement.
• Total number of support issues submitted via electronic mail covered under the annual
support agreement.
17 Severity 1 classifications are only for systems in production. The highest severity allowed during implementation is Level 2.

• The billing rate per consultant level required by the LGU in excess of what is covered
under the support agreement.
Post-production Support Services

Post-production support or the “hand-holding” stage immediately follows system (or
production) roll-out. This support will typically cover onsite consultants for the duration of the
agreed post-production support period. The support period ranges from 30 days to a maximum
of 6 months depending on the support agreement or what was stipulated in the engagement
contract. Onsite consultants assist end-users with system use and administration and help
technical staff resolve problems that may arise during the post-production period.
To facilitate the competency development of the LGU’s IT staff in supporting every aspect of the
BPLS software, it is recommended that staff avail themselves of post-production services via a
support escalation process. There are several levels of support:
• Level 1. The BPLO personnel will normally be trained to recognize a problem, identify
and describe the problem and its behavior, record the problem via screen shots or
incident reports, classify the problem, and conduct initial problem resolution.
• Level 2. Second level support issues are more technical and will require deeper skills in a
number of areas (e.g., hardware, network, software, database, or process).
• Level 3. Sometimes escalation to the third level is warranted and this involves support
from the product developers themselves. Based on the service level agreement, the
response time in the support escalation process may be defined. Some LGUs may decide
to train their personnel to provide services comparable to third-level support.
5.4 CHANGE MANAGEMENT

Managing change in the LGU as a result of the BPLS automation project begins at the earliest
stages of process streamlining and computerization. Failure to manage the change process will
lead to resistance, which if left unresolved will pave the way to process circumvention.
Promoting eBPLS Improvements

It is important to secure support for procedural changes due to the BPLS automation reform.
The support of LGU personnel and the general public for the BPLS automation reforms can be
solicited as follows:
• Conduct consultative meetings with stakeholders, involving members of the local business
community (representing small, medium, and large businesses) progressively throughout
the project lifecycle. The LCE, through the implementation project team, could work
with local industry and civil society groups like the local business chambers, Rotary Club,
Lions Club, and other stakeholders, to introduce and get feedback on the eBPLS process
changes via the Barangay assemblies.

• Conduct information and education campaigns (IECs) three months before implementation,
during implementation, and after implementation. IECs should target operational staff,
heads of departments involved in business registration, and the business community.
• Distribute informational materials such as brochures and leaflets in both English and the
local vernacular to every business group, in all of the Barangay in the LGU, in key areas of
the city/municipal hall, and by putting informational posters on publicly accessible bulletin
boards throughout the LGU.
• Revise the Citizen’s Charters of the LGU, which is required by ARTA, to reflect the
streamlined business registration procedures as a result of the BPLS automation project.
Structuring the Change Management Program

To maximize the effectiveness of the LGUs’ change management program, activities should
meet the needs of executives, middle managers, front office staff, IT personnel responsible for
implementing eBPLS, as well as the business sector and other civil society groups.
Change management is not confined to how work is done or to training end-users in a new
system. It involves convincing those affected by change that the reforms will not only improve
the efficiency and effectiveness of the LGU, but will also improve the image of the LCE and the
LGU personnel. It focuses on modifying thinking and behavior, which is integral to achieving the
goals of the BPLS automation project. Persons most likely affected by computerization would be
business operators, BPLO personnel, Treasury personnel, document verifiers, encoders, cashiers,
department heads and inspectors, IT and system administrators. Table 5.4 organizes change
management programs by target group. The second column specifies activities to resolve issues
that may arise in the target group, and to immerse the group in the specified areas.
Table 5.4
LGU Change Management Programs by Target Group
Target Group Change Programs (Intervention) Measure of Success
Mayor or LCE Legislative compliance, collaboration, and Able to craft executive orders and
transparency ordinances supporting automation by
Institutional capacity facilities acquisition and maintenance, IT
and IT-enabled personnel recruitment,
Basic IT skills (personal navigation of
training, and retention.
screen processes, generation of outputs,
and analysis of reports) Able to personally use the system and its
outputs in decision making.
Able to clearly communicate the benefits
of its use to staff and constituents.

Target Group Change Programs (Intervention) Measure of Success

Department Heads Operational and procedural efficiency Zero backlog on all applications in process,
meets the 10 day processing limit, and able
Communication and problem to submit intelligent reports to aid in
intervention skills executive decision support.
Basic computing skills
Front Office Staff eBPLS process orientation Familiar in the use of all available system
features, can navigate confidently through
Basic computing skills the screens, able to locate stored data using
eBPLS software navigation training the systems search features, able to print
reports.
Communication and customer care skills
IT Group Systems administration including back- Reduced dependence on vendor support to
ups, archiving, business operations resolve system issues, able to perform
regular maintenance work on the system.
continuity, and disaster recovery
Database administration
Security management
Issues resolution management
Applying and testing systems upgrades or
software patch updates
Customers Conducting business in the LGU Fewer registration applications returned
Note: Change management programs could employ a variety of techniques and methods to facilitate adoption of new process and tools until
these become fully integral to the individual’s work routine or pattern.
Resolving Problems Related to BPLS Automation

Given the magnitude of the BPLS automation project and the reforms that will be introduced,
the LGU may need to solicit and disseminate feedback from LGU staff and business applicants.
LGUs, however, should not attempt to introduce substantial changes or reforms all at once.
Instead, they should introduce changes progressively within a prescribed period of time so
people can adjust to the new processes and other changes introduced by the automated BPLS.
Some proposals to facilitate information exchange include the following:
• Provide a way for end-users or customers to provide feedback anonymously to the LCE on
matters concerning the process, and personal experience in dealing with LGU staff. This
may be done by setting up a suggestion box, Post Office box, email address or a mobile
number where reactions, comments, complaints, suggestions, or commendations may be
sent.
• Establish user groups of end-users, systems administrators, trainers, and members of
the business community to promote continual, well-rounded process and system
improvement.

• Progressively orient end-users and customers to the Help Desk to log their inquiries, requests,
issues, and problems. Ensure that the help desk has the capability to provide services by
means convenient for the customer (e.g., phone, fax, SMS, email, social networks). The
help desk centralizes the flow and management of problem tickets using a “single point
of contact.”
Setting up a basic help desk could be as simple as (1) have two dedicated telephone numbers
that business can call to log their issues; (2) using a preprinted and serialized “scripts” of
questions that help desk staff ask each caller; and (3) training support staff on basic business
registration processes and telephone support techniques using the vernacular or English.
Alternatively, the LGUs can use a word processing application installed in a dedicated pc
workstation in place of hand-written forms to capture answers to questions from the
preprinted form.
The help desk could be in the form of (1) a specialized center where issues are immediately
resolved by authorized support staff or (2) an issue routing center where issues are logged and
documented and then routed to a predefined internal or departmental specialist. Either way,
creating a help desk need not be complex. The most important thing is to provide a dedicated
number for businesses that have questions. This is also an effective way to quell customer
frustration by ensuring that inquiries are routed to the person or group that is qualified to
answer questions or queries as quickly as possible.

6. SUSTAINABILITY OF THE
BPLS AUTOMATION REFORMS
6.1 CONTINUAL PROCESS IMPROVEMENT
The BPLO is the face of the LGU in the business community and its processes should be
improved continually in keeping with the expectations of business and with the speed of
economic growth. To ensure that such improvement is part of BPLO daily operations after
automation of the BPLS, the following training and competency programs as well as systems and
technology environment are recommended.
Training and Competency Development Programs

• Develop BPLS Automation training materials with the BPLO and other LGU departments;
focus on improving BPLS domain expertise, process knowledge, communication,
customer service, language, and problem solving skills.
• Immerse LGU staff in continuing education short course/classes in BPLS domain expertise,
process knowledge, services, and communication skills.
• Implement a quality management framework and system (ISO, TQM, EFQMS, etc.) to
develop awareness of every aspect of LGU operations, particularly the BPLO operations.
Systems and Technology Environment

Managing the systems and technology environment (e.g. networks, applications, database, and
transactional data) is crucial to ensuring that the automated BPLS maintains the highest levels of
availability.
• Daily Backups. The IT department or IT specialist must backup transactional data of the
BPLS on a regular nightly basis. As a matter of convention, backup media must be stored
in a secure location outside the facilities of the data center. Incremental backups must
be scheduled on a nightly basis and full systems backup must be scheduled on a monthly
basis.
• Business Continuity and Disaster Recovery Planning (DRP). The disaster recovery plan for the
BPLS must be integrated into the general DRP plan of the IT department. DRP strategies
help ensure that, in case of natural or human-caused disaster, the LGU can immediately
restore its services without losing any mission-critical data.
• System Updates. Periodically, software vendors release software patches to fix
compatibility problems, patch security threats, or improve software performance. These
updates should not be made automatically or without first running a full systems backup.

SUSTAINABILITY OF THE BPLS AUTOMATION REFORMS
System updates need to be performed only by qualified IT resources.

• Preventive Maintenance and Capacity Planning. Network and database administrators
need to work in tandem to monitor the usage demand on the network and servers on
a regular basis to plan the necessary steps to ensure maximum availability (based on a
predetermined service level with the users) of all equipment used by the automated
BPLS. As a rule, system usage and growth of the automated BPLS will parallel economic
activity of the LGU. The IT department will need to plan and appropriately forecast the
growth of production systems inclusive of the automated BPLS.
6.2 CHALLENGES IN AUTOMATING BPLS

The government’s intent to eradicate corruption and raise the country’s standing in global
surveys of competitiveness has given momentum to BPLS reform. BPLS Automation is being
promoted as a way for LGU’s to have efficient business registration procedures and to raise
current JMC standards to be on par with or even better than the country’s neighbors in
ASEAN. As with any procedural change, BPLS automation will be resisted, which is why
change management is so important. The motivating factor for reform continues to be the
administration’s dedication to pursuing BPLS reforms.
Challenges to computerization range from high staff turnover, resistance to change, poorly
defined requirements and funding, to the many anecdotal references already cited in the Bureau
of Local Government Finance (BLGF)18 publication. Suffice it to say that the challenges to BPLS
automation and their underlying causes will only be addressed as new systems are successfully
implemented, as people are continually trained, and as the implemented solution is sustained and
carefully managed.
A major contributor to these challenges is the tendency of LGUs to make procedural

exceptions. This is most evident in contracts and procurements, cost-cutting conventions, labor
rigidity that leads to unqualified or under qualified personnel, and a lack of security measures
and validation controls in the existing systems. These challenges will persist until LGUs make a
concerted effort to transform unnecessary exceptions and operational short-cuts into clearly
defined processes bound by defined security and validation controls.
6.3 FUTURE DIRECTION IN BPLS AUTOMATION REFORMS

The Information Technology Office under the Department of Science and Technology (DOST)
is handling the functions of the former National Computer Center. With the current change
in administration, the BPLS automation project of the national government is taking on a new
direction under the leadership of DOST. The following are some of the proposals:
18 Linking Up LGU Operations – A Guide to Computerization of Tax-Related Functions in Local Government Units, Bureau of Local
Government Finance © 2009, pp 6-7 (ISBN 978-971-93448 1-0).

• Improving the automated BPLS to be consistent the JMC standards and making the new
software available to the LGUs, principally the municipalities.
• Undertaking a survey on the status of BPLS Automation in cities and municipalities as a guide
to the assistance that government will provide as part of the reform program.
• Strengthening public-private partnership in BPLS Automation Reforms by encouraging
software developers to develop BPLS software solutions for the LGUs using the base
design specifically formulated for BPLS Automation.
• Protecting the interests of LGUs through assistance in identifying credible software vendors
and implementation providers using a system of accreditation where products and
services of software vendors and system integrators who transact with LGUs will be
accredited.
• Organizing a system of compliance audit groups with private sector participation to assist
the NCC in ensuring that LGUs are protected in the eBPLS solutions that will be
purchased.
BPLS Automation provides an opportunity to improve BPLS standards. Computerization

could introduce additional efficiencies to BPLO operations by providing LGUs with a way to
further reduce the number of process steps from five to three. As shown in Figure 6.1, business
registrants will be able to complete the application form and pay for the assessed fees using
web-based automated BPLS. This will eliminate the function of assessors, lighten the task of
cashiers, and improve the LGUs’ cash position since registrants will be required to pay all fees
and taxes before processing begins, much like conventional e-commerce wherein customers pay
for their orders before receiving a product.

Possible Future Process Step Reduction through Computerization

p
g
p
Figure 6.1

APPENDIX A. BPLS Unified Form

APPENDIX A. BPLS Unified Form

APPENDIX B. Guide Questions for
BPLS Streamlining Design
Guide Questions Possible Actions
Which of the requirements being Reduce similar requirements to just one submission at the start of the
asked of the applicant are the same process.
for many offices? (ex. Copy of DTI or
SEC registration) For example, the DTI or SEC registration copy should only be required
when the applicant first applies. Any information in the registration (ex.
capitalization) required by other offices can be inserted into the information
field in the unified application form.
Putting in place an information-sharing mechanism among LGU offices will
reduce the need for multiple requirements.
Are applicants required to undertake Examine which of the steps are necessary and which can be eliminated. Look
many steps? Why? at the ‘Purpose’ column of the Process Table to check that a step serves a
legal purpose.
Enabling the sharing of information databases can reduce steps and
interfaces.
Are applicants being required to fill Unified Form
out many application forms asking for
the same information? (ex. name,
address)
After the analysis of the gaps and the One Stop Shop
initial identification of the reform
strategy, the next stage is the writing
of the action plan. Are applicants
going to many offices – within one
building or to many buildings -
lengthening travel time?
Are applicants waiting in line for a Add more frontline staff, especially during peak periods
long time?
Provide a separate window or different schedule for applicants representing
many applications
How long is the transaction time? Compare it to the benchmarks. If it is longer than good practices, observe
what is taking time for the frontline staff to process a transaction. For ex., if
the reason is that the information supplied by the applicant is incomplete or
wrong, provide written instructions, through Frequently Asked Questions
for example, before the applicant is entertained by the frontline staff.
If part of the length of the transaction time is for securing the signature of an
official, authorize more than one official to issue approvals
How long is the total processing time Compare it to the benchmarks. Using these guide questions, undertake
for backroom processes? process simplification to backroom processes. Decide whether service
standards (time within which a service must be completed) can be imposed
to reduce the time needed to complete a step.
51
APPENDIX C. Functional
Specifications Plan
Section Content
1 Background and Rationale
Needs Assessment
Solutions Framework
2 Current Process Flows
Future Process Flows
3 System Features and Functionality
User Interface Design and Navigation
System Workflow and Approval Routing
System and Data Flows
System and Data Security
Exceptions Handling and Processing Flows
Data Management and Connectivity
4 Reports Generation
Standard Reports (seeded)
Ad Hoc Reports
Data Extraction
5 Functional Specifications Sign-Off
52
APPENDIX D. IT Project Lifecycle
It is important to distinguish between the project plan and the project schedule. Although these
terms are commonly used interchangeably, they are different documents.
The Project Schedule is a document containing a breakdown of phases, activities, and tasks
organized in a predefined order of execution within a target timeframe, and the resources
required to complete those tasks within the given timeframe.
The Project Plan is a rationalization of the project detailing organizational priorities, the
project schedule, assumptions, project objectives, execution strategy, the project organization,
the communication plan and so forth. The project schedule is only a subset of the project plan.
The sequence of structured activities, at a bare minimum, must be organized into phases. The
structure of phases must be based on a logical order of relationships between activities and
operational priorities so that LGU executives could appreciate the specific order in which
specified activities would be executed.
The structure of the project as defined in the project plan will form the basis of the project
schedule’s high level phases. A project schedule can come in different formats. There are also
numerous tools available in the market to aid planners in developing a project schedule using
their preferred format. Regardless of the tool or format, a project schedule must have the
following details: Task Name, Task Duration (Start and Finish), and Resources (labor and material)
per Task. Tasks are the granular-level (lowest level) detail of any project schedule arranged in
logical and hierarchical sequence against which time and resources are assigned.
After defining the structure of phases and activities, the next step is to define the project
organization or the constitution of material and labor resources required to accomplish the
planned objectives and project deliverables.
The conventional phases of a systems project or a project lifecycle are as follows:

• Definition
• Design
• Development
• Testing
• Deployment and Training
53
The Definition phase consists of a series of activities to explicitly document the requirements
to successfully deliver the targeted system which includes activities such as the conduct
of a gap analysis, system requirements specification, organizational change requirements,
capacity requirements definition and so forth. LGUs have the option of conducting evaluation,
assessment, and organizational readiness activities as part of this phase in cases where such
information does not yet exist.
The Design phase consists of activities that build on the foundation of information gathered
during the Definition phase. It is during the Design phase that the project team translates the
business information gathered during the Definition phase into an explicit technical execution
framework covering low level details inclusive of the data model, user interface design, and
application behavior (program logic). In cases where a commercial-off-the-shelf (COTS) or
packaged application will be implemented, it is during the Design phase when the project
team, using previously defined requirements, identifies system configuration details and the
accompanying data requirements.
The Development phase consists of activities to implement and unit test the approved design
specifications secured from the previous phases of the project. In cases where a packaged
application will be implemented, the development phase largely consists of technical and
functional configuration as well as reports customization activities to ensure that the packaged
application functions and behaves according to the approved specifications.
The Testing phase consists of simulations to functionally validate that the behavior and outputs
of the target system in accordance with approved specifications. The testing activities are broken
down into three categories: systems testing, integration testing, and user acceptance testing.
• Systems testing activities are geared to ensure that the physical and software components
functions according to the approved specifications.
• Integration testing activities are geared to ensure that software and data interfaces inter-
operate and exchange correct data between modules of the target system.
• User acceptance testing or UAT activities are geared to directly engage end-users in full
regression testing or testing the behavior and output of the target system from end to
end using a predetermined set of approved test scripts.
The Deployment and Training phase consists of activities to roll-out the fully tested system
into the targeted production environment, and activities to train end-users and systems
administrators on the use and management of the target BPLS.
54
There are a minimum of two environments required by any systems project: Implementation
and Production. Ideally a Testing or Staging environment should also be present as a bridge
between the Implementation and Production environments.
• The Implementation Environment consists of the hardware (servers, networking,
workstations, etc.) equipment and software applications (such as integrated development
environments or IDEs, database system, etc.) needed to implement the approved designs
of the target system.
• The Production Environment consists of the hardware equipment and software systems
required to operate the target system for operational use. As a rule of thumb, systems
deployed into the production environment must never be modified or indirectly
accessed to maintain system performance and data integrity.
• The Testing or Staging Environment, while optional, will prove valuable particularly in
environments that plan to progressively customize applications already deployed in a
production environment. It is in this environment where the target system is extensively
tested by end-users particularly during UAT activities.
As a rule of thumb, the testing or staging environment must be configured to be exactly the
same as the production environment.
55

BPLS Automation Planning and Implementation Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BPLS Automation Planning and Implementation Guide

Uploaded by

Copyright:

Available Formats

BPLS AUTOMATION

2. Impact on BPLS Standards 5

3. Readiness and Needs Assessment 12

4. Planning for BPLS Automation 24

5. Managing the Implementation of the Automated BPLS 35

6. Sustainability of the BPLS Automation Reforms 45

Appendix A. BPLS Unified Form 49

BFP Bureau of Fire Protection

Assessment (business permit and licensing context). Process of determining

Managed for USAID/Philippines by Nathan Associates Inc., LINC-EG—Local

The purpose of the BPLS Automation Guidelines is to provide the local

USAID has supported Philippine local governments in improving the administration

In July 2010, USAID/LINC-EG supported the national government in establishing

ALID DAVID CAMARA

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 1

1.1 BENEFITS OF AN AUTOMATED BPLS

Other benefits of automating registration include the following:

2 BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

1.2 INFORMATION SYSTEMS STRATEGIC PLAN

4 Refer to Executive Order 47 dated June 27, 2011.

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 3

1.3 GUIDE SCOPE AND LIMITATIONS

4 BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

2.1 UNIFIED FORM

2.2 NUMBER OF PROCESS STEPS

Registration of New Businesses

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 5

Documentary Required Best

3 One-time All documents from Front Office – One-time 1-2 days or 5 – 15

SOURCE: DTI-DILG Joint Memorandum Circular No. 1, series of 2010.

6 BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

2. BPLO. Front office processing and interface with business registrant.

Renewal of Existing Businesses

2.3 PROCESSING TIME

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 7

BUSINESS REGISTRATION (THE 5-STEP PROCESS) NEW APPLICATIONS

CASHIER / BFP & OTHER LGU

Complete Receive Conduct Site Review Registrant

Review Issue Assessment

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

Client LGU Timeframe

4 One-time Assessment of Front Office Collect and issue 1 hour 10 – 15

SOURCE: DTI-DILG Joint Memorandum Circular No. 1, series of 2010.

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 9

BUSINESS REGISTRATION (THE 5-STEP PROCESS) RENEWAL OF PERMITS

BFP & OTHER LGU CASHIER /

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

2.4 REQUIRED SIGNATORIES

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 11

3.1 TECHNICAL WORKING GROUP

3.2 BUSINESS PROCESSES

Prepare the BPLS Process Table

12 BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

Assess the BPLS Process

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 13

Prepare the Action Plan

Reform Specific Expected Date of Responsible Resources Support

14 BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

3.3 ORGANIZATIONAL READINESS

7 Based on Annex D of the BLGF’s Linking Up LGU Operations Manual.

BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE 15

1. Is there commitment at various levels in the LGU to computerize?

16 BPLS AUTOMATION PLANNING AND IMPLEMENTATION GUIDE

Prepare the Action Plan