It's more than a month now since we blocked facebook and youtube from our office network from 8:30 - 12 and 1:30 - 5:30. I wonder how people here have reacted over it.
It's actually been debated since early 2009, whether to do just that or not. The primary problem then was loss of productivity. Restaurant City and Farmville (along with Plants vs Zombies) were grave dangers to work time. Even before, non-stop chatting in YM was already an issue. It seems staying largely unseen by the boss was enough temptation for quite a few.
By large, I resisted having a permanent ban on FB along with some other sites. We want our people to choose the right thing, and be smart about stuff like this. FB and other sites can be good stress relievers after all.
2009 Team building helped some with that regard. After that, clear and blatant abuse were less common, although it was still much of a problem with people stationed in unwatched, far away places.
2010 however brought even more important reasons to do something about it. High bandwidth streaming sites like Youtube was hurting our VPN and email. Then sometimes, we find people fighting because of some status update commonly read wrong or hitting too close to the heart, or below the belt. People here are getting their fun in FB at the expense of others, methinks.
(There's something ironic when people fight because of something said in Facebook. It was supposed to help connect people. But on those times, it was virtually helping connect punches between otherwise good friends. People stopped talking straight. FB was replacing normal human interaction. Scary.)
One interim step I took was to temporarily disable web access to certain sites to specific computers that were found exceeding their "breaktime" quota. But that's unnecessarily Big Brother for me.
So we're now where we are. In the mean time, they're off-limits during work hours. Hello to shorter lunch time.
Showing posts with label IT. Show all posts
Showing posts with label IT. Show all posts
Wednesday, February 16, 2011
Wednesday, March 3, 2010
Service Desk Soft Start
A month ago, I talked about an information systems module for our service department. Since then, Amici's IT and Service department have held a few meetings on expectations and mock ups of the module, not surprisingly called Service Desk.
Service Desk was designed after our company's short-lived experiments with Request Tracker and OTRS, both open source web-based issue trackers. We did not push through with web-based issue trackers because we needed a customized system well integrated with our current stack. We were not looking for a help desk system, but instead a service and schedule management system. OTRS felt too IT-ish, which our company is not. Request Tracker lasted longer (two weeks) but lack of integration to our CRM proved cumbersome.
That was two years ago. Service Desk collected dust instead of improving our service because the process to interface with it, the overall structure of our Service Department was only to be stabilized two years after.
Last Saturday, we formally introduced Service Desk to our sales force. Rather than the original rudimentary table design that stressed outstanding service requests, it sported a new employee daily schedule interface that gives focus on scheduling constraints and resource management. The table design is still available as an alternative view, but for the main target users, our service managers and our sales team, the daily schedule view remains the obvious choice.
Sales brought up an obvious request. Should not Sales be allowed to create the service requests themselves? Then, our service managers need only to monitor outstanding requests so that they can schedule them appropriately.
This option is readily available, should service request processes be revised. In fact, this was the original design of the Service Desk. However, it remains to be seen whether the size of our company shall warrant the process change.
Right now, when Sales request services, they usually call any one of three service managers to relay details and wait for an SR number. Sometimes, it's easier to jot down details on a small sheet of paper and to hand that personally to our service managers. Unfortunately, in practice a lot of waiting may have to be done either way. Jotting down details on paper also duplicates encoding of the service request.
The proponents of the separation of duties for Service Requests and Job Orders espouses the advantages of the analogous Sale Order and Sale Invoice system.
The requestors will themselves encode their requests, reducing the encoding bottleneck by a factor up to 7 (20+ people to encode their own requests, rather than 3 to encode everyone's requests), and also reduce typical errors such as misspellings. A standard work flow for requesting service is simply clicking on a Service button from the related Sale Invoice to automatically fill up fields and link the sale to the service request. Service Managers can then focus on providing appropriate schedules for all outstanding requests.
The communication pattern between requestors and service managers will be different. Instead of the current poll-waiting method whereby Sales busily waits for an available Service Manager to communicate his requests, a message passing, event-driven methodology becomes natural. This is akin to email instead of the telephone.
Requestors will not have to wait for an SR number. The computer system automatically provides a request ID and even notifies requestors via email any updates on their requests. Service Managers will be notified of any pending requests and are free to schedule them. Scheduling those requests in turn automatically notifies requestors of the new schedules.
I believe the SR <> JO system is appropriate especially for big companies. The poll waiting communication pattern is obviously inefficient for large volume of issue/service tickets. For our company however, our lower volume might not give enough points to either methodologies.
Service Desk was designed after our company's short-lived experiments with Request Tracker and OTRS, both open source web-based issue trackers. We did not push through with web-based issue trackers because we needed a customized system well integrated with our current stack. We were not looking for a help desk system, but instead a service and schedule management system. OTRS felt too IT-ish, which our company is not. Request Tracker lasted longer (two weeks) but lack of integration to our CRM proved cumbersome.
That was two years ago. Service Desk collected dust instead of improving our service because the process to interface with it, the overall structure of our Service Department was only to be stabilized two years after.
Last Saturday, we formally introduced Service Desk to our sales force. Rather than the original rudimentary table design that stressed outstanding service requests, it sported a new employee daily schedule interface that gives focus on scheduling constraints and resource management. The table design is still available as an alternative view, but for the main target users, our service managers and our sales team, the daily schedule view remains the obvious choice.
Sales brought up an obvious request. Should not Sales be allowed to create the service requests themselves? Then, our service managers need only to monitor outstanding requests so that they can schedule them appropriately.
This option is readily available, should service request processes be revised. In fact, this was the original design of the Service Desk. However, it remains to be seen whether the size of our company shall warrant the process change.
Right now, when Sales request services, they usually call any one of three service managers to relay details and wait for an SR number. Sometimes, it's easier to jot down details on a small sheet of paper and to hand that personally to our service managers. Unfortunately, in practice a lot of waiting may have to be done either way. Jotting down details on paper also duplicates encoding of the service request.
The proponents of the separation of duties for Service Requests and Job Orders espouses the advantages of the analogous Sale Order and Sale Invoice system.
The requestors will themselves encode their requests, reducing the encoding bottleneck by a factor up to 7 (20+ people to encode their own requests, rather than 3 to encode everyone's requests), and also reduce typical errors such as misspellings. A standard work flow for requesting service is simply clicking on a Service button from the related Sale Invoice to automatically fill up fields and link the sale to the service request. Service Managers can then focus on providing appropriate schedules for all outstanding requests.
The communication pattern between requestors and service managers will be different. Instead of the current poll-waiting method whereby Sales busily waits for an available Service Manager to communicate his requests, a message passing, event-driven methodology becomes natural. This is akin to email instead of the telephone.
Requestors will not have to wait for an SR number. The computer system automatically provides a request ID and even notifies requestors via email any updates on their requests. Service Managers will be notified of any pending requests and are free to schedule them. Scheduling those requests in turn automatically notifies requestors of the new schedules.
I believe the SR <> JO system is appropriate especially for big companies. The poll waiting communication pattern is obviously inefficient for large volume of issue/service tickets. For our company however, our lower volume might not give enough points to either methodologies.
Tuesday, February 16, 2010
IT and You
As a small company in growing pains, Amici has grown accustomed to incessant process changes in constant search for the best way of doing things. Some changes though not merely whims without reasons are due perhaps to hypotheses and not so scientific methods of experimentations. Most will have foundations in text book analyses and prescriptions of friends in or out of the industry. It should be good then that we are not so big as to be inflexible. We strive to be agile.
Information technology is one pillar our company leans on to improve itself. And as much as changes live and die and evolve through generations, information technology only outlives itself due to constant makeover. Processes such as counting inventory, tracking serial numbers, monitoring expenses, preparing our next orders, etc. find themselves renovated as ideas and plans come into fruition in every next iteration of our information system.
People, whether cooperative or antagonistic towards each and every change, play the bigger part in moulding our company evolution. IT changes that find huge backlashes are commonly flawed in design or expectations. People are the users who swear by the strengths of and curse the weaknesses of our system. They demand change more demandingly than mere routine pro-activeness.
There is however a natural wall between people and IT. On one side, a lot of people do not know what to seek from IT. They live with what's there, and dismiss inefficiencies as way of life. And then on the other side are people who see IT too magically, without practical consideration to time or budget. IT though materially inexpensive costs time and manpower.
Also, the software developer who receives requests from users is too often distanced to understand what users expect. Users themselves do not know too well their requirements, and the software developer challenged in communication is only happy to guess usage and expectations.
The solution of course is a comfortable entanglement between IT and users. But before that, Amici IT should seek organization and sustainability.
Information technology is one pillar our company leans on to improve itself. And as much as changes live and die and evolve through generations, information technology only outlives itself due to constant makeover. Processes such as counting inventory, tracking serial numbers, monitoring expenses, preparing our next orders, etc. find themselves renovated as ideas and plans come into fruition in every next iteration of our information system.
People, whether cooperative or antagonistic towards each and every change, play the bigger part in moulding our company evolution. IT changes that find huge backlashes are commonly flawed in design or expectations. People are the users who swear by the strengths of and curse the weaknesses of our system. They demand change more demandingly than mere routine pro-activeness.
There is however a natural wall between people and IT. On one side, a lot of people do not know what to seek from IT. They live with what's there, and dismiss inefficiencies as way of life. And then on the other side are people who see IT too magically, without practical consideration to time or budget. IT though materially inexpensive costs time and manpower.
Also, the software developer who receives requests from users is too often distanced to understand what users expect. Users themselves do not know too well their requirements, and the software developer challenged in communication is only happy to guess usage and expectations.
The solution of course is a comfortable entanglement between IT and users. But before that, Amici IT should seek organization and sustainability.
Sunday, January 31, 2010
Number Business
Like any normal business, we work with numbers here in Amici Water Systems. Sales agents compute discounts and totals for each of their sales; the collector or cashier computes change for the customers; sales supervisors add up her group's sales for the quarter and their expenses; HR handles the intricate payroll in a very complicated spreadsheet in OpenOffice.org; marketing does forecasts for her latest marketing project; service and project managers work with limited sets of resources and time to prepare service estimates and project schedules; managers and accountants look at financial statements.
Unlike a lot of businesses however, our major products are heavily about numbers. When we size water heaters for your home, swimming pool, or a hotel, we may need basic numbers like the number and flow capacities of showers, the number of bathtubs, the dimension of your pool and the ambient temperature of water and atmosphere, or the number of rooms in a hotel or occupancy rate during peak hours for water heating. The number of solar panels needed, the output capacity of heat pump water heaters, the storage capacity of hot water tanks form a system to provide enough hot water at a desired temperature for however your business uses hot water. Pumps and tanks are sized according to required volume and pressure as well as horizontal and vertical distances between water source and installation site. The appropriate models of swimming pool pumps and filters for your swimming pool depend on the volume of your swimming pool as well as its usage. Our products are technical. They are a number business.
Due to the nature of our business, it is important for our people to know their math, and do it well. Though our various product trainings cover to a degree specific product physics informally, there is so much room for improvement in our technical training program. Formalization of the program, including gradation and tests, will be helpful in the long run in educating our people.
Arming our people with efficient tools are just as important. While the old-fashioned basic calculator is still the preferred equipment of many, due to its convenience and portability, the versatile spreadsheet and other computer programs are available for more advanced computations. Our product catalog has a few pages devoted to conversion tables. We have a compilation of spreadsheet/form templates for various common calculations in our day to day business to speed response time. At one point, I've even written a small unit conversion tool to help convert basic units of measurement we use in our company. Nowadays, with internet access being almost a given, Google's built in calculator has been a boon to quick and easy calculations.
My personal favorite calculator, however, is Qalculate. Unfortunately for Windows and Mac users, it is only available under Linux. (Fortunately for our company, we use Ubuntu, a fairly easy-to-use Linux distribution, in which installing Qalculate is just a search and a few clicks away.) Qalculate not only features a robust scientific mode but also unit conversions, currency conversions, and even calculus. As an example of its power, you can enter 6 kilowatt hour to Btu and it gives you 20.472747 kBtu. Computing the desired gpm pump requirement for a residential swimming pool 10 meters long, 6 meters wide, and 5 feet deep is simply entering the following expression:
10 meters * 6 meters * 5 feet / 8 hours to gal/min
It gives an answer ~ 50.324776 gal / min.
Unlike a lot of businesses however, our major products are heavily about numbers. When we size water heaters for your home, swimming pool, or a hotel, we may need basic numbers like the number and flow capacities of showers, the number of bathtubs, the dimension of your pool and the ambient temperature of water and atmosphere, or the number of rooms in a hotel or occupancy rate during peak hours for water heating. The number of solar panels needed, the output capacity of heat pump water heaters, the storage capacity of hot water tanks form a system to provide enough hot water at a desired temperature for however your business uses hot water. Pumps and tanks are sized according to required volume and pressure as well as horizontal and vertical distances between water source and installation site. The appropriate models of swimming pool pumps and filters for your swimming pool depend on the volume of your swimming pool as well as its usage. Our products are technical. They are a number business.
Due to the nature of our business, it is important for our people to know their math, and do it well. Though our various product trainings cover to a degree specific product physics informally, there is so much room for improvement in our technical training program. Formalization of the program, including gradation and tests, will be helpful in the long run in educating our people.
Arming our people with efficient tools are just as important. While the old-fashioned basic calculator is still the preferred equipment of many, due to its convenience and portability, the versatile spreadsheet and other computer programs are available for more advanced computations. Our product catalog has a few pages devoted to conversion tables. We have a compilation of spreadsheet/form templates for various common calculations in our day to day business to speed response time. At one point, I've even written a small unit conversion tool to help convert basic units of measurement we use in our company. Nowadays, with internet access being almost a given, Google's built in calculator has been a boon to quick and easy calculations.
My personal favorite calculator, however, is Qalculate. Unfortunately for Windows and Mac users, it is only available under Linux. (Fortunately for our company, we use Ubuntu, a fairly easy-to-use Linux distribution, in which installing Qalculate is just a search and a few clicks away.) Qalculate not only features a robust scientific mode but also unit conversions, currency conversions, and even calculus. As an example of its power, you can enter 6 kilowatt hour to Btu and it gives you 20.472747 kBtu. Computing the desired gpm pump requirement for a residential swimming pool 10 meters long, 6 meters wide, and 5 feet deep is simply entering the following expression:
10 meters * 6 meters * 5 feet / 8 hours to gal/min
It gives an answer ~ 50.324776 gal / min.
Wednesday, December 30, 2009
Amici Back Online
After 3 days of backing up our commercial website from a shared hosting provider, choosing a new VPS provider, and doing all sorts of configurations in Linux to make our small website run a bit better in just 360mb of RAM, we're back online.
Actually, I don't think visitors noticed any technical problems in our website the past few weeks, since the problem with the previous host only occurs when logging in our website to administer it. But the past 3 days of tinkering have brought frequent downtime. (I'm very new to web server administration.) Hopefully, the current setup will work better now, and provide smoother usage of our site.
p.s. For the technically curious, the frequent downtime yesterday and today were due to thrashing, out of control memory and disk swapping, due to improper configuration of the Apache HTTP server under minimal RAM. Last night was a little better as the memory resources of Apache were minimized. This morning, I was able to setup nginx to work on top of Apache and reduce dependency on Apache.
Actually, I don't think visitors noticed any technical problems in our website the past few weeks, since the problem with the previous host only occurs when logging in our website to administer it. But the past 3 days of tinkering have brought frequent downtime. (I'm very new to web server administration.) Hopefully, the current setup will work better now, and provide smoother usage of our site.
p.s. For the technically curious, the frequent downtime yesterday and today were due to thrashing, out of control memory and disk swapping, due to improper configuration of the Apache HTTP server under minimal RAM. Last night was a little better as the memory resources of Apache were minimized. This morning, I was able to setup nginx to work on top of Apache and reduce dependency on Apache.
Website Woes
For the past two weeks, our company website is having problems for logged in users (which is usually me). The problem is with the seemingly recent policy of our host on maximum PHP script memory, set at a paltry 32MB, not enough to run a full duty Drupal installation.
While updates in the website are far in between, not being able to log in means new updates will be farther still. It's time to try a new host. Budget needed Year 2010.
While updates in the website are far in between, not being able to log in means new updates will be farther still. It's time to try a new host. Budget needed Year 2010.
Subscribe to:
Posts (Atom)
Posts
