gourmet team mailing list archive

[Harald Franzen <harald.franzen@xxxxxxxxxxxxxxxx>]

Hello everybody!

Thanks for accepting me into the team, Bernhard!

Just to introduce myself briefly; my name is Harald Franzen, originally 
Dutch but I run a small business in France. This business provides 
services to cave divers that visit this remote region in France where I 
live, and the services we offer include lodging, filling scuba tanks for 
diving and a restaurant (and a few things around it). In essence, I am a 
provider of logistical services for people that visit this region to go 
diving.

This winter -a relatively "slow" period of the year- I was looking to 
improve my logistics around the purchasing of food, and I set out to 
write a database with recipes, so I could quickly create shopping lists 
for the food we need to purchase. At a certain point I had the luminous 
idea :-) to see if somebody hadn't already invented the wheel. And 
indeed, the wheel had been invented by Thomas Hinkle and the wheel 
seemed to be round too!

Thanks guys for an excellent job! You have made my life a bit easier and 
that's fantastic!

When I started playing around with Gourmet, I ran into some issues (that 
are particular to my setup) and hence I got in touch with Bernhard who 
kindly invited me into the team.

It may be useful to know that in my "previous life" I used to be a 
management consultant, specialised in business process improvement and 
as such worked on roughly 15 ERP implementations for various medium 
European companies. I am not a software specialist, but I do understand 
processes and their translation into concepts that software specialists 
then transform into working code.

I have -with the aid of Bernhard- already forked Gourmet to work on the 
Dutch translation - I noticed some issues there, but I also have a Use 
Case to present, as preparing food on a scale inbetween the average 
houshold and a big restaurant is part of what we do here in France. I 
have pasted that Use Case below, for your information. Maybe some of the 
things I find within the inner workings of Gourmet entice you to develop 
software for it. I do fully understand that some of my requests/wishes 
are really a big ask, so do not worry about that: I will work with 
whatever is available :-)

Also, I do apologize beforehand, because obviously -apart from a yet 
limited user experience- I know little to nothing about Gourmet and the 
way you have chosen to translate functionality into workable code, 
database structures, and so on. So whenever I write something really 
stupid, please forgive me!

Best regards and looking forward!


Harald

---------------------------------------------------------
Gourmet Use Case

Small restaurant, serving on average roughly 3 guests per night al year, 
totalling around 1200 servings per year, consisting of breakfast, a 
packed lunch (guests will leave the premises during the day) and a 
dinner comprised of starter, main course (including side dishes) and a 
dessert.

Effectively, as the restaurant is part of a seasonal business (cave 
diving center hosting and providing to cave divers three main services: 
lodging, filling of diving bottles and food), the occupancy is around 
5-6 "in season", peaking to 12-16 guests at peak moments. Scalability in 
purchasing is important, as the turn-over rate is almost instantaneous 
(3-4 days cycle during "slower" times, 2 days during "busy" times). 
Storage space is limited and product freshness paramount.

Shopping logistics are difficult: the business is located in a remote 
area and the nearest bigger supermarket is 35 minutes driving away. 
Also, all operations are catered for by two people, so efficiency and 
effectivity are very important -- any ingredient not purchased at the 
right time means an extra shopping trip, incurring losses in time and 
money (because of the extra driving).

The restaurant is not allowed -due to legal restraints- to offer a menu, 
unless guests have particular dietary requirements (vegetarien, food 
allergies and so on). That is to say that the composition of dinner -and 
thus the ingredients and quantities thereof- is determined by the 
restaurant, not by the guests.

The pool of recipes includes all types of dishes (soups, starters, fish 
courses, meat courses, all desserts, etcetera, etcetera), contains 
roughly 200 recipes, varying from classical French dishes to Asian, 
African and North American foods. Typically, the restaurant will cycle 
through different regions of origins and create an alternation of the 
staple food (so rice one evening, pasta the next, potatoes after that, 
and so on) and an alternation of the character of the dishes (so not 
different stews evening after evening, for example).

Next to planning and executing dinners, the restaurant uses a list of 
ingredients that will need replenishing from time to time (for breakfast 
and lunches, mainly; or stock items for general use -- like ground 
coffee, salt, (olive) oil, and so on).

Each winter (low season), the current "book of recipes" is reviewed and 
some recipes will become obsolete whilst new recipes will be added in a 
bid to improve quality, reduce cost and renew the offer especially for 
those guests that return frequently (2 -- 3 times a year).

Next to purchasing efficiency, efficiency in quantities (reducing or 
preferably iliminating waste) is an important goal. The restaurant aims 
at a 700 gram dinner each evening, providing quality and healthy food 
for physically active guests. The aim to reduce waste has not only an 
ethical, but also a financial background.

In order to achieve quality food at low cost, all meals are prepared 
"from scratch", using fresh ingredients where possible and avoiding 
pre-processed foods where ever possible. This is the chosen method to 
add as much value as possible.

The restaurant seeks to more efficiently and effectively create shopping 
lists, automatically scaling for varying occupancy, reducing time to 
generate the shopping list from the proposed/planned meals and avoiding 
errors in copying ingredients' lists (currently an activity that is done 
manually).

1. Ideally, conversions of ingredients' units should be "perfect" 
(currently, a shopping list might read "sugar: 100 g + ½ tablespoon + 1 
teaspoon") and on the shoppings lists should emerge in "units of 
purchase" (currently this feature does not exist in Gourmet).

2. A quantitative "larder" function (so stock keeping functionality) 
should be available (the current "larder-functionality" in Gourmet 
already offers some functionality to assist in eliminating ingredients 
that are already on stock, however, this is a manual operation).

3. Order points could be added and purchase of (almost) out-of-stock 
items suggested, by enabling reduction of the larder once the user 
indicates a certain menu or menus has/have been "executed".

4. If "unit of purchase" functionality is available, pricing information 
per unit could be added, giving a cost structure per meal. This is not 
only relevant in a business environment, but it can help common 
households see, that freshly prepared foods are actually cheaper than 
pre-processed foods and that the effort of cooking "from scratch" values 
the time investment made in preparing a meal.

5. Pull-down menus (like "categories") should ideally be alphabetized.

6. The shopping list should be printable in a pre-designed order, to 
mimick the logistical layout of the supermarket of choice (currently not 
supported, but a work-around has already been implemented in the initial 
setup of Gourmet for the restaurant).

The business has a relatively extensive IT-layout, offering access to 
shared files and databases throughout in order to facilitate business 
processes. Hence, a central MySQL-database was setup on a server, 
accessible to all workstations and different users. Servers and 
workstations run Ubuntu Linux (Servers use the most recent LTS version, 
workstations the most recent release). It is expected that in 2014 or 
shortly after, the IT-infrastructure will be augmented by tablet 
computers running Ubuntu, making Gourmet physically mobile.









--
Harald Franzen
Centre de Plongée Souterraine
Les Trois Fonts
46330 BLARS
La France
I: www.lotcavediving.eu
E: harald.franzen@xxxxxxxxxxxxxxxx
T: +33(0)565-214122
M: +33(0)6-45639437