My customer grew from a small enterprise to an SP/Mobile operator network very quickly. I want to guide them on how to operate their network, so I am looking for a document for this.
I've found the following websites quite useful for this: http://www.google.com/search?hl=en&q=Change+Management http://www.google.com/search?hl=en&q=Network+Management http://www.google.com/search?hl=en&q=Daily-Operations-tasks+network http://www.google.com/search?hl=en&q=Change+Order http://www.google.com/search?hl=en&q=Trouble-Ticketing-system http://www.google.com/search?hl=en&q=escalation+procedures http://www.google.com/search?hl=en&q=troubleshooting+processes http://www.google.com/search?hl=en&q=backup+procedures http://www.google.com/search?hl=en&q=Network-Inventory No, this is not a joke. I checked every one of the above URLs and you *WILL* find useful information at each one. And here is an important tip. Install a database server (Oracle, PostgreSQL) for general use and make sure that everyone has ODBC/JDBC access to it. Then ban the storage of information in spreadsheets and make it a habit to ask pointed questions about where data is stored when you are in meetings. Order the DB Admins to create any tables that people ask for in the "general use" database but to advise people on table design, for instance field types (IP addresses are not VARCHAR). Some attempt should be made to ensure that important fields are consistent between users since at some future date, tables may need to be joined. But these rules need to be applied with a light touch because the goal is to KEEP DATA OUT OF SPREADSHEETS. Many modern companies operate using 1950's style processes shuffling spreadsheets through email instead of shuffling paper through the mail carts. That is counterproductive. It is far better to emulate 1970's/80's companies who could only justify the vast expense of computers by simplifying processes and centralizing data on shared databases. Once a spreadsheet starts to become a valuable source of data, the data should be stuffed into the database where it can be shared, kept up to date, be viewed consistently by all parts of the business, and joined with other data for reporting purposes. Then, when it makes sense to build or buy an application centered around a database, you already have a source of clean consistent data ready and waiting. --Michael Dillon