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.
Sunday, January 31, 2010
Saturday, January 30, 2010
Traditions
Our company as organizations do grows its traditions with age. Though our company history is more than 30 years already, more than half the average lifespan of a corporation, our company in its current form is very young.
The first five years have been about products. With a small office for three people, our company grew slowly but steadily, selling good products at fair prices while maintaining low overhead. Tradition has been opening at day and closing at night, and the year-end inventory.
The next years after up to now however have brought dramatic changes. Leadership developed and luck blessed our company. Now, it's really about the people, good people, selling good products. More social traditions followed.
Some of our major company events such as Christmas parties and Team-building are recent traditions. They do not make much sense in a company of 3 or 4 persons.
Some haven't earned their keep to be called traditions. This new year's company outlook missed this year (Or I missed it somehow.) Last year's sportsfest and moon cake festival were unceremoniously aborted after typhoon Ondoy. Nevertheless, this year holds promise for the sportsfest's continuation with an already scheduled chess tournament.
These recent company traditions arose from normal progressions of relationships. As our company focused on people, relationships among develop to form cohesive groupings. Working with more people preludes socializing with more people. When there's stability, social interaction in and out of office contribute to each other's growth and group cohesiveness. Lack of maintenance on the other hand brings about apathy and division.
It would have been lacklustre if traditions were to arise only for its own, as a pure business decision without magic of innovation and communication, with a goal first and foremost to promote bonding as if it can be plasticized so conveniently. (But one can still grow from there, giving probably adaptation and creativity.)
Our sportsfest (or the idea of) have been borne in part from common sports played by fellow officemates. Our weekly basketball have been quite steady for the past year. Badminton, though it hasn't caught on, has fans such as yours truly. Chess? Table tennis? People among are finding common grounds of activities, on which to share and find unity.
As an young, agile company, we can expect traditions to come to show the Amici way. More people coming in means more possibilities of formation. When people go out, we expect changes. We must be alive to maintain the best traditions and let bad traditions die quietly.
The first five years have been about products. With a small office for three people, our company grew slowly but steadily, selling good products at fair prices while maintaining low overhead. Tradition has been opening at day and closing at night, and the year-end inventory.
The next years after up to now however have brought dramatic changes. Leadership developed and luck blessed our company. Now, it's really about the people, good people, selling good products. More social traditions followed.
Some of our major company events such as Christmas parties and Team-building are recent traditions. They do not make much sense in a company of 3 or 4 persons.
Some haven't earned their keep to be called traditions. This new year's company outlook missed this year (Or I missed it somehow.) Last year's sportsfest and moon cake festival were unceremoniously aborted after typhoon Ondoy. Nevertheless, this year holds promise for the sportsfest's continuation with an already scheduled chess tournament.
These recent company traditions arose from normal progressions of relationships. As our company focused on people, relationships among develop to form cohesive groupings. Working with more people preludes socializing with more people. When there's stability, social interaction in and out of office contribute to each other's growth and group cohesiveness. Lack of maintenance on the other hand brings about apathy and division.
It would have been lacklustre if traditions were to arise only for its own, as a pure business decision without magic of innovation and communication, with a goal first and foremost to promote bonding as if it can be plasticized so conveniently. (But one can still grow from there, giving probably adaptation and creativity.)
Our sportsfest (or the idea of) have been borne in part from common sports played by fellow officemates. Our weekly basketball have been quite steady for the past year. Badminton, though it hasn't caught on, has fans such as yours truly. Chess? Table tennis? People among are finding common grounds of activities, on which to share and find unity.
As an young, agile company, we can expect traditions to come to show the Amici way. More people coming in means more possibilities of formation. When people go out, we expect changes. We must be alive to maintain the best traditions and let bad traditions die quietly.
Wednesday, January 20, 2010
Service Now Next Door
Along the restructuring of our service group this early came well thought plans, wishful experiments and wide-eyed thinking. Within a few days from conception, we now have service request forms printed in triplicate, serialized, carbonized, glued, and in archaic colors. Our service team has left the cramped office for a more spacious room. They got some local phones sometimes working and then some. Internet connection and wiring was assisted by yours truly. And just today, they have another computer to play with!
The service request forms serve to put in writing whatever service is tasked to do. And by that, I mean anything. It actually surprised me the first couple of times I saw some non-operational tasks put in the service forms. The service request forms (which I secretly call Job Order forms (because that's what I called them back in July last year in its computerized version)) are creatively colored white, pink, and yellow. Not. They're also conveniently segregated into two series: A and B. I'm not sure which service group is A and which is B, but I'm pretty sure the service group has that written somewhere. Last week, I was trying to encode some of the forms in the computer. Unfortunately I encountered quite a number of cacographical issues.
I think they'll have to have some kind of filing cabinets sooner or later. Although from what I see with the implementation so far, you wouldn't want to browse through them just to look for one particular form. Thinking about filing so much data makes me want to study library science some time.
The service team has finally left our office, to the rightful dismay of office mates who habitually answer the phones. One thing that made service a bit problematic was that it can be hard to get in touch with them. Sometimes, you can't get one complete sentence from them without some preemptive phone call to distract them. Although the communication issue is with much merit, the space problem is just as big an issue. We have now three guys (1.4 + .75 + .85 = 3) sharing one chair, one table, one computer and half a phone. When they get visitors (and they get lots of them), it can be crowded. So moving them out sort of won that one. At least temporarily. I think the communication issue can be fixed in more creative ways.
Which is why they now have two local numbers. Three would have been better. But right now, the two are not yet perfectly working. So let's work that out first. It would have been fantastic if they can have a sort of local trunk number which our main office can dial to ring any available phone on their side. That is certainly plausible if I can convince management to invest in an Asterisk server to replace our dinosaur of a PABX. Other options include video intercom and instant messaging.
What happens if you've got 3 computer novices in an air conditioned room, well hidden from prying eyes, and two computers with internet? Chess death match anyone? Well not really. They haven't gone that far except for the nearly ubiquitous Facebook. Now one is helping the other how to do some Empathy, while having fun with Cheese. Then there's the question of how to shut down.
The service request forms serve to put in writing whatever service is tasked to do. And by that, I mean anything. It actually surprised me the first couple of times I saw some non-operational tasks put in the service forms. The service request forms (which I secretly call Job Order forms (because that's what I called them back in July last year in its computerized version)) are creatively colored white, pink, and yellow. Not. They're also conveniently segregated into two series: A and B. I'm not sure which service group is A and which is B, but I'm pretty sure the service group has that written somewhere. Last week, I was trying to encode some of the forms in the computer. Unfortunately I encountered quite a number of cacographical issues.
I think they'll have to have some kind of filing cabinets sooner or later. Although from what I see with the implementation so far, you wouldn't want to browse through them just to look for one particular form. Thinking about filing so much data makes me want to study library science some time.
The service team has finally left our office, to the rightful dismay of office mates who habitually answer the phones. One thing that made service a bit problematic was that it can be hard to get in touch with them. Sometimes, you can't get one complete sentence from them without some preemptive phone call to distract them. Although the communication issue is with much merit, the space problem is just as big an issue. We have now three guys (1.4 + .75 + .85 = 3) sharing one chair, one table, one computer and half a phone. When they get visitors (and they get lots of them), it can be crowded. So moving them out sort of won that one. At least temporarily. I think the communication issue can be fixed in more creative ways.
Which is why they now have two local numbers. Three would have been better. But right now, the two are not yet perfectly working. So let's work that out first. It would have been fantastic if they can have a sort of local trunk number which our main office can dial to ring any available phone on their side. That is certainly plausible if I can convince management to invest in an Asterisk server to replace our dinosaur of a PABX. Other options include video intercom and instant messaging.
What happens if you've got 3 computer novices in an air conditioned room, well hidden from prying eyes, and two computers with internet? Chess death match anyone? Well not really. They haven't gone that far except for the nearly ubiquitous Facebook. Now one is helping the other how to do some Empathy, while having fun with Cheese. Then there's the question of how to shut down.
Saturday, January 9, 2010
Service Revamp
This morning held a much awaited sales-service meet. I would say much awaited as I've been expecting a major restructuring of service for a while now. Our company has met much difficulties the past couple of years, ballooning in expenses and manpower, as well as service requests and back orders. We've gone through several persons each doing his or her best to take on the daunting role of the service manager. There were high expectations to be met. Some have gone their separate ways. Some have shifted to roles a bit less challenging. And then some have persevered through thick and thin, goals met or unmet. We've added people with different levels of training. But after the past year, we still aren't there. We're in much need of foundational and procedural improvements.
Unfortunately, I wasn't able to join in much of the meeting. Actually, I might have missed the session completely if not for perky ears on an early curious morning. I did my best to attend, even if I felt somewhat uninvited, although I skipped the delicious breakfast of tuyo and salted eggs -- dietary compulsions. Alas, with other important things to attend, it seems I only got to the intro and finale. It might have been exponentially interesting to get to the gist of the meeting.
What can we expect? From what I see, there will be papers and more, and trees crying. Service order forms, return forms, differentiation of repair and delivery/installations -- seems standard fare in traditional companies. They will do much good in making our service operations measurable -- as long as they're properly implemented. Splitting the service group to Repairs and Delivery/Installation can help in response times and specializations. Ultimately it will be about customer satisfaction. Expect things to become much much better.
~~~
As a side note, it seems I can't say much given how out of the loop I sometimes feel now about various company processes. As I'm more of an IT and Supply Chain personnel, I'm still trying to see how the changes will fit in the overall scheme. On one end, it's disheartening not to have input about the changes being implemented. I've already wrote a service module in our in-house enterprise system, though it needed more love and attention, and actual use and tuning. (I'm all for evolutionary programming, although right now I'm by myself.) On the other end, I'm still excited to work on redesigning the service management module. The past month, I've been contemplating on getting more hands-on service management experience. There are naysayers on implementing it through computers, valid reasons all -- personnel "computational complexity", keeping things simple, etc. But I don't really see the conflict. It's a design problem. That's the exciting part.
Unfortunately, I wasn't able to join in much of the meeting. Actually, I might have missed the session completely if not for perky ears on an early curious morning. I did my best to attend, even if I felt somewhat uninvited, although I skipped the delicious breakfast of tuyo and salted eggs -- dietary compulsions. Alas, with other important things to attend, it seems I only got to the intro and finale. It might have been exponentially interesting to get to the gist of the meeting.
What can we expect? From what I see, there will be papers and more, and trees crying. Service order forms, return forms, differentiation of repair and delivery/installations -- seems standard fare in traditional companies. They will do much good in making our service operations measurable -- as long as they're properly implemented. Splitting the service group to Repairs and Delivery/Installation can help in response times and specializations. Ultimately it will be about customer satisfaction. Expect things to become much much better.
~~~
As a side note, it seems I can't say much given how out of the loop I sometimes feel now about various company processes. As I'm more of an IT and Supply Chain personnel, I'm still trying to see how the changes will fit in the overall scheme. On one end, it's disheartening not to have input about the changes being implemented. I've already wrote a service module in our in-house enterprise system, though it needed more love and attention, and actual use and tuning. (I'm all for evolutionary programming, although right now I'm by myself.) On the other end, I'm still excited to work on redesigning the service management module. The past month, I've been contemplating on getting more hands-on service management experience. There are naysayers on implementing it through computers, valid reasons all -- personnel "computational complexity", keeping things simple, etc. But I don't really see the conflict. It's a design problem. That's the exciting part.
Subscribe to:
Posts (Atom)
Posts
