Proposed Improvements to the Building Information System “BCIS”

Product Approval Module

1.       Overhaul the business functions of the entities application process.  The entities application process has been the source of frequent concerns and problems from staff and users.  The following are the list of concerns as experienced by staff and users:  (1) There is no clear understanding of what a REVISION (editorial vs. technical) and RENEWAL mean and when to use each; (2) Only one status for entities, whether logged in or not.  The status should change for consistency with the application process (i.e.  The status of entities applications should change when they submit renewal to “Pending Accreditation”; (3) Accreditation entity should have to upload proof of compliance.  Currently they only have to check a box and upload equivalency; (4) No entity renewals or revisions should be allowed on DENIED, SUSPENDED, REVOKED status.  They should register as a new entities; (5) Notification email should be expanded to notify of new entity registration and show both TBA and DCA payment portions; (6) Create a status for expired QA; (7) Create verification function for QA agencies audit of manufacturers ’ QA program; and (8) There should be no grace period.  Currently, the approval date extends 1 year when the entity application is “Pending Accreditation” and is moved to the Approved status.  The date is extended 12 months each time the application is moved from pending to approved status.  The only time this date should be extended is when the applicant pays for the one 12-month cycle.     

2.       Add provisions to the BCIS to allow all communications between entities with regard to the product approval and entity application to be conducted through a specified dialogue in-box designated on the BCIS.   Add a dialog box for DCA to take notes on the applications for historical purposes (i.e. documentation of issues with the application for future reference).  

3.        Establish Standard Procedures for Reviewing Applications by the Administrator. 

4.       Improve User’s Interface.  For example, allow general users to see only those items they have access to, allow logged in users to see the full menu items they have access to…etc.

5.       Improve input screen/revision for product application.  Improve the ability to delete or add a product to be more intuitive.  The applicants are not comfortable with the way the screen operates.  

6.       Improve search screen.  Add Search & Clear buttons to the top of the search criteria screen.  Change the organization drop down to reflect alpha search instead of one long string with the option of displaying all.   Product model number or name search should be more intuitive.  Search should allow numbers or alpha search to identify close matches.   Product description search should be more intuitive.   The search results screen should have more information, product model number or name and/or description. 

7.       Others:

(1)  Emails:   Keeping track of the receipts for payments made on-line.  The customer cannot go back and print a receipt once the transaction is complete.  Maybe dump in the administrator’s inbox.   Have a history of the application in the administrators “Manage applications” section.

(2) Manage Applications:  Allow color in the comment box.

 (3) RODUCT APPLICATIONS:  Add FL and Rev number to print out on the top middle of each Validation Checklist. 

(4) Product approval:  (a) on product applications, improve look of HVHZ section of the chart.  Possible Fix: One change would be on “Approved for Use in the HVHZ: No” to have the system via radio button selection in the application state “Not approved for use in the HVHZ” or “Approved for Use in the HVHZ”; (2) Add less than / greater than to Product Approval Search page for design pressures; (3) To delete an erroneous product in product approval you have to go inside the product and delete it.  Could be easier; and (4) Under product chart have spacer to separate FL number from “History” link.  They are too close together as they are now.


 

Code Modification Module

Improve the following functions of the Code Modification Module: 

1.        Improve reporting.   Codify all reports created as part of current triennial code modification process.

2.        Create reports/tracking charts for compiling and presentation of proposed code changes to be submitted under the Glitch code change process.

3.       Improve reports available to users for consistency with those available to staff.

4.       Create a program to allow linking base document(s) to a specific proposed code change and allow for an automatic update to the base document(s).

5.       Research means to improve compatibilities between the module database and Crystal Report.

   

Local Amendment and Declaratory Statement Module

Present status:  All information/data are currently had to be entered by staff.  Majority of the information are entered as attachment.  Input fields are limited.  Search functions are limited. 

Redesign the module as follows:

Program the Declaratory Statement submittal process and the local amendment process to be an integral part of the module database.  This will improve the input function of the database and search function to both staff and users.