SI5 Complete Sample Project

[kevinmikelonis]

Attached are a series of files containing a complete proposal, design documents, and select management reports for a real project built entirely in SI5.

The database for the project was built in SI5 MMPD using the Process DSG STARTER MASTERTABLE and modified to match the specific business processes for our client, a System Integrator and D-Tools user. The client mastertable database was then loaded with our high quality archived data and new data created for products not already in our archives to meet the needs of our client's project.

The project was then created in SI5 TEXT, based on core product selections for each System and Room which were made by the System Integrator for their client, the end user of the system designed, engineered and documented in D-Tools SI5.

After the TEXT project was assembled, and evaluated using the D-Tools Management Reports, the design documents were generated in Visio one System at a time by using the filtering tools in the Project Datamatrix (new for SI5 and awesome!) and moving items to Visio from the TEXT project.

Some things make note of and look for when reviewing these project documents:

THE PROPOSAL:

It's a stock SI5 'enhanced' proposal, it's big, but succinct.

It's BIG because of the following:

1. The room allowed in the report for 'images' in the left column which is built into all SI5 enhanced proposal reports.

- This takes up space even when you do not use images. We believe the compressed proposal images provide no value in the proposal and only add more database management hours to a System Integrator's already impacted scehdule. We left one image in the database and the project proposal for your own evaluation.

- Let's play 'Where's Waldo' and see if you can find it! The first Forum Member to e-mail me the Manufacturer, Model, and Dimensions for the product whose image is included in the proposal gets a $25 Amazon gift card!

2. The large graphics in the proposal.

- I like them, the RGB and BNC connectors, they are cute, but they do take up a lot of space over and over.

3. The repeated System Descriptions throughout the proposal.

- We build in a short and simple description of each system listed in the Zones list of the mastertable database. Since proposals are in most cases best presented and understood when grouped By System-By Location, that System Description repeats everytime the System appears in another Location (Room). We want to find a cure for this other than moving to Rich Text and deleting the redundancies, but that certainly is an option for now, about 15 minutes of work, not much when you consider the overall effort of this large project

It's SUCCINCT because of the following:

1. Significant use of Packages.

- Both summarized and non-summarized.

2. Signifcant use of Item Accessorization.

- All items in the database and therefore the project are 'Hidden' when they are accessories, save for a few exceptions where it was important to show the accessory item.

3. What's missing?

- A short scope of work fitted into the description field for each Room location. We built the database and project documents in this engagement, and did not sell the system to the end user. Our client did that and therefore must define the deliverable features for use and control of the systems and interfaces in each room.

The description field for each Room is a great place to explain breifly just what the Touchpanel/Keypad/Structured Wiring Plate is capable of doing in each space.

We consider these performance and functional specification extremely important to an integrators ability (and most importantly their client's) to know when the project is finished, after all, it is features that Systems Integrators are selling, not equipment..


THE DESIGN DOCUMENTS:

These are done in Visio, the floorplan was imported from CAD after opening it in CAD and cleaning it up, they are easy to read, and even include some color.

They are easy to read because:

1. All Systems are not all on the same plan view, multiple plan views were created.

2. Rooms are assigned numbers and numbered consistently in the plan, the D-Tools project information (framework as we like to call it) and are tied to the

COMPONENT ID schema.

- Notice each shape in each room matches up its COMPONENT ID with its room number, a great check and balance while developing plan views and schematics, and really strong when filtering the project datamatrix.

3. Room Names added to each plan view on their own layer.

- This allows them to be moved independently on each page to allow for placement of each shape on the plan.

4. Color is used CATEGORICALLY assigned by layers.

- We are using shapes from our exclusive Enhanced Stencil Suite D-Tools SI5 shapes, and color was added to each page quickly by coding the layers which follow CATEGORIES.

- The use of color should be considered carefully in your documentation, it is not always neccessary, and can add complexity. I have never seen color plans to build a building with, or install, plumbing, HVAC, or electrical. Ask you installers if it helps them before plotting everything in color.

- We really miss the ability to include the MODEL of a wire as part of the shape on the schematic page in SI5. You can use the shape with model number if you 'right-click' and change shape one wire at a time on the schematic page, but that is not practical. Having the wire model as part of the shape automatically is mapped as such in your database was in SI4 and removed from SI5. This feature eliminated the need in our view to color code wires on the schematic page. Because our I/O signal and terminal type naming in all our data is follows a signal type heirarchy, and is clear, consistent, and non-ambiguous, looking at the signal type gives an experienced installer the needed information to know the cable type to be used.

5. Enhanced Shapes!

- Using our Starter Mastertable and Enhanced Stencil Suite to build your database will result in having definitive shapes pre-mapped to your data.

- This will make most all of the shapes seen on the plan views of this project default shapes to your data when the shape is placed onto the drawing. So again, a huge reduction in database management by nearly eliminating custom item to shape mapping.

6. Schematic pages are ordered by signal types.

- This keeps like signal types on the same page, so each page is easy to read with few 'line jumps', and only a few wire types, aganin reducing the need for color coding. Look for the special callouts where wires are broken out of bundled cable but include their own COMPONENT ID.

- Color is used CATEGORICALLY assigned by layers. Not totally neccessary, but pretty and when done by layers and not mapped into the shape sheet, very quick and easy to implement. Funny thing about color, is that in our industry, we run out of definitive colors fast, and need to use 'shades' of colors which tend to vary based on the level of colored ink in plotters! If you are relying on color coding, what then? BRING BACK THE ABILITY TO MAP THE WIRE WITH MODEL NUMBER to the schematic page!


THE MANAGEMENT REPORTS:

We included a Pick List By Phase-By Manufacturer to show just how complete a project can be with regard to materials when it is built from an engineered
database that leverages Accessorization and Packaging. We also included a Project Hours By Phase Report to show the hours included in the job.

1. Pick List

- Note the Manufacturers ending in -DNO: this is product that we DO NOT ORDER. This is because the item may come with another product that we DO ORDER and needs to be its own item in the database because it has it's own unique I/O's and needs to be in a separte location fromit's parent item on the drawings.

-DNO items are most all the time accessories parent items. Look for NETMEDIA and NETMEDIA-DNO in the pick list.

- Note how many items are in this report that are not seen in the proposal. Small items are hidden from the client proposal through Packaging,

Accessorization, and most importantly, proper adding of packages and products to projects in TEXT, dragging and droppinig shapes to reverse engineer a client proposal does not result in a proposal that can be easily presented to a client.


2. Project Hours Report

- Note the hours in the sub-phases of MISC, DESIGN, MGMT

- Note the phases of Programming and Advanaced Programming. Programming is the programming done to things like Surround Processors, DVD players, Phone System KSU's, Security Panels. Advanced Programming in this project is programming done by an outsourced programmer. Systems like, Crestron, AMX, Lutron are increasingly programmed by outsourced programmers in Systems Integration Companies. Here we have an estimated of hours (charged at a different rate) for those programming hours that are outsourced, separate from those programming hours done in house. Defining business process and building a database to reflect it makes this work into a project automatically.

- Note the phase of Warranty Support which carries hours and cost for those 'go-backs' after the job is completed.

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++

We would love to see your feedback on the techniques used in the creation of this project so we can try other things and share more with our user community.

Our forum has been very quiet while we worked through the transition to SI5.

If you are looking for more out of D-Tools, we help you get it.

If you bought D-Tools to get your project documentation dialed in and flowing efficiently to the field so you can retain the profit you projected for your projects, we deliver it.

Reminder! This content and commentary only covers the project proposal and design documentation. The level of consistency and big picture thinking that is built into the database that created this project, and the methods used to build this project flow through to the OPERATIONS and BACK OFFICE functions of the System Integrator as well.

If you are a D-Tools user and employee of a Systems Integrator that owns D-Tools and want access to this level of consistency and ease in your project development and design documentation, get your superiors to call us and setup an online review with our staff to see what can be done to get a real RETURN ON INVESTMENT MULTIPLE from their D-Tools purchase and THE BEST in Professional Services from Process Dealer Services Group.

[dharmonyav]

Very nice work guys!

[bfourney]

I understand the logic behind using room numbers, but what are your thoughts about using names instead? The guys I work with don't seem to like that numeric format for a couple of reasons, the main one being that you pretty much have to decipher it if you're looking at a wire label or scematic.

For instance wouldn't LIVING-CBL-003 be more intuitive than 113-CBL-003? I understand about the limitations with having to abbreviate long names and such for rooms like HER MASTER CLOSET but a component ID of seven letters or so should be long enough for most any combination. That is not to say that each room shouldn't still have a number assigned, but I can't seem to find a good enough reason to use numbers alone when names are so much more intuitive to the person in the field.

[kevinmikelonis]

Good points you bring up, however, without numbering there is always room for misinterpretation.

For instance, a project with 4 bedrooms, called Bedroom 1, Bedroom 2, Bedroom 3, Bedroom 4 will always require a look at the plans to see which Bedroom is 1, 2, 3, and 4.

Same goes with projects having 2 garages...also His closet, Her commode lead to ambiguity that can be cleared by looking at the plans where the room names and their numbers are located.

I have run many projects where crews call a room by two different names, where 1 wire was marked 'Foyer' and another wire run from the same room, perhaps on a different day, or by a different tech called it 'Entry'.

Numbering requires a look at the plans! This is a good thing!

The other reasons for this practice is to help keep the component ID short.

Long Component IDs are aggrivating to deal with on plans, wire labels, and wire checklist reports.

Trying to make room for a long component ID at the end of a wire shape on plans is made more difficult when component ID's are longer than they have to be.

Wire checklist reports have a column for component IDs and they support 9 characters total before the text begins to wrap and become more prone to reading errors by the users of the reports.

If you are using a P-Touch or Rhino labler, it is nice to use large font sizes so wire labels can be read by the techs working in closets and mechanical rooms.

That longer component ID required to differentiate rooms with similar names runs out of room on popular 1 1/2" wide labels when a 'readable' font size is selected.

Our practices, recommendations, and methods are based on practical knowledge of D-Tools, and our own experience in operating a systems integration company here in Paso Robles, Ca